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1 3.  ABSTRACT (Mddruti  ra  warda) 

-The  military  services  have  been  experiencing  problems  in  the  adequacy  of  their  weapon 
systems'  diagnostic  capabilities.  Thera  are  available  a  vailety  of  techniques, 
procedures,  standards,  and  devices  which  can  be  applied  to  the  acquisition  of  a  system's 
diagnostic  capability.  However,  this  type  of  Information  appears  in  a  variety  of 
reports,  military  standards,  specifications,  and  other  documents.  The  objective  of  this 
document  Is  to  collect  such  Individual  and  diverse  pieces  of  Information  as  they  relate 
to  the  function  of  weapon  system  design.  This  guide  Is  one  of  the  three  guides  aimed  at 
the  government  program  manager,  the  contractor  program  manager,  and  the  system  designer. 
This  guide  la  specifically  designed  to  help  the  design  engineer  to  meet  or  exceed  the 
diagnostic  requirements  Imposed  on  the  system  he  Is  designing.  . 
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DIAGNOSTIC  DESIGN  ENCYCLOPEDIA 


PREFACE 

One  of  the  major  missions  of  the  Rome  Air  Development 
Center  (RADC)  Is  the  development  of  procedures  and  techniques  for 
improving  the  readiness  and  supportablllty  of  weapon  systems.  In 
support  of  this  mission,  RADC  has  sponsored  a  myriad  of  studies, 
analyses,  and  developments  that  have  resulted  In  techniques,  standards, 
and  procedures  aimed  at  reaching  this  goal. 

In  the  19808  all  the  military  aervicea  have  recognized  the 
importance  of  Improving  the  diagnostic  capability  of  weapon  systems  as 
a  means  for  rapid  troubleshooting  and  repair  of  these  systems.  The 
research  and  development  efforts  conducted  by  RADC  are  reflected  In 
this  guide  by  synthesizing  the  results  of  these  many  efforts  and  filling 
gaps  to  provide  both  government  and  industry  with  a  compendium  of 
procedures  and  techniques  which  ^^ay  be  used  to  Improve  the  fielded 
weapon  systems'  diagnostic  capabi'  /. 

Many  other  programs  nave  made  the  contributions  that  are 
included  in  these  guides.  Information  has  been  freely  Included  from 
various  military  service  and  Industry  work,  Among  these  Is  the  Air 
Force's  Generic  Integrated  Maintenance  Diagnostics  Program 
(GIMAOS).  The  GIMADS  Program  has  made  available  much  of  Its  Air 
Force-oriented  material,  which  Is  included  In  this  guide.  In  this  manner, 
material  from  all  of  the  other  service  organizations  Is  now  available  for 
Joint  Service  use. 


Three  (3)  guides  have  been  written  which  are  aimed  at  the 
following  users; 

0  Government  Program  Manager 
0  Contractor  Program  manager 
0  System  Designer 

Thus,  the  guidance  material  required  by  a  specific  user  will  be  included 
In  one  of  these  three  (3)  guides. 

It  Is  believed  that  this  guidance  material  represents  a 
comprehensive  look  at  the  problems  in  fielding  a  satisfactory  diagnostic 
capability  and  a  structured  system  engineering  approach  to  solving  these 
problems.  RADC  solicits  comments  on  this  guidance  material,  as  a 
means  for  Improvements  In  the  coming  years. 
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WHY  ALL  THIS  WORRY  ABOUT  DIAGNOSTICS? 

Let's  put  the  diagnostic  problem  In  its  proper  perspective. 
You’ve  got  a  problem  with  /our  automobile  and  you  turn  to  a  mechanic 
for  help.  Historically,  you  realize  that  the  problem  may  be  fixed  or 
Indeed,  for  some  reason,  you  may  have  to  go  back  one  or  more  times 
before  the  problem  Is  corrected,  or  you  give  up.  We  are  talking  about 
automobiles.  Automobiles,  which  a  manufacturer  has  produced  tens  of 
thousands  of  times,  have  a  hietoricai  record  of  their  reliability  and 
maintainability  and  have  been  redesigned  and  reengineered  many  times. 

When  comparing  your  automobile  to  an  extremely  complex 
weapon  system  that  Is  pushing  the  state  of  the  art  and  produced  In 
limited  numbers,  with  questionable  historical  data  on  their  operation,  one 
can  easily  understand  the  magnitude  of  the  problem. 

It  Is  not  the  purpose  of  this  guide  to  provide  a  comprehensive 
discussion  of  the  diagnostic  problems,  but  rather  to  guide  government 
and  Industry  people  in  circumventing  known  problem  areas.  However,  to 
understand  the  magnitude  of  the  problem  a  few  examples  follow. 

In  one  slx*month  period,  at  one  F>16  tactical  fighter  wing,  over 
13,600  maintenance  manhours  were  reported  for  the  processing  of 
unnecessary  removals.  This  equals  about  20  people  just  working  on 
troubleshooting  these  "good"  Items. 

A  DoD  Task  Force  on  Productivity  In  Support  Operations 
(1986)  found  that  20  to  50  percent  of  avionics  maintenance  actions 
resuHed  in  removal  of  Hems  with  no  evidence  of  failures. 

The  deployment  of  an  avionics  Intermediate  shop  for  fighter 
aircraft  to  a  remote  location  can  require  anywhere  from  three  to  eleven 
C-1 41 B  equivalent  loads.  In  wartime,  there  just  will  not  be  enough  cargo 
aircraft  to  respond  to  this  need.  In  peacetime.  It's  just  plain  costly. 

The  diagnostic  problem  is  not  unique  to  any  one  service,  nor  to 
any  one  type  of  weapon  system.  It  manifests  itself  throughout  the 
military  senrices.  The  problem  can  be  an  engineering  or  a  field  problem. 
It  can  be  a  man  or  a  machine  problem.  It  can  be  a  wartime  or  a 
peacetime  problem.  It  can  be  a  prime  system  or  a  supportabillty 
problem.  The  problem  manifests  Itself  In  different  ways  for  different 
types  of  weapon  systems,  but  the  consequences  are  all  the  same-long 
times  to  troubleshoot,  removal  of  items  which  have  not  failed,  long 
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logistic  tails,  and  an  overall  lack  of  confidence  in  the  entire  diagnostic 
capability.  Obviously,  the  result  is  lack  of  readiness  and  a  waste  of 
dollars  and  manpower. 

There  are  a  multitude  of  reports  which  adequately  describe  the 
problem,  Two  of  these  reports  give  a  comprehensive  picture  of  the 
problem  and  possible  solutions.  These  are: 

"Isolation  of  Faults  In  Air  Force  Weapon  and  Support 
Systems,"  Committee  on  Isolation  of  Faults  In  Air  Force  Weapon  and 
Support  Systems,  Air  Force  Studies  Board,  Commission  on  Engineering 
and  Technical  Systems,  National  Research  Council. 

"Report  for  the  Department  of  Defense  on  the  Implementation 
of  Integrated  Diagnostics,"  prepared  by  the  National  Security  Industrial 
Association's  Integrated  Diagnostics  Working  Group,  September  1984. 


HtSTOmCAIXY  THI  nitOlO  0IAQNO8T10  CAPAMUTY  HAS  NOT 
UVED  UP  TO  THE  PHOMISES 


Government  and  Industry  must  share  the  responsibility  for 
what  has  hsppened  In  the  past.  On  the  government's  side,  there  tends 
to  be  a  lack  of  knowledge  on  how  to  specify  what  is  needed  and  how  to 
make  sure  the  government  gets  what  it  needs.  On  the  contractor's  side 
la  a  lack  of  understanding  of  the  Importance  of  fielding  a  satisfactory 
diagnostic  capability  and  still  maintain  schedule  and  cost  limitations. 
Hopefully,  the  series  of  guides  produced  under  this  program  will  help  to 
alleviate  this  situation. 

The  military  services,  as  well  as  the  Office  of  the  Secretary  of 
Defense,  understand  the  urgency  of  this  problem  and  have  established 
multimillion  dollar  programs  to  help  alleviate  this  situation,  both  from  a 
technology  and  a  management  perspective.  For  the  most  part,  these 
programs  are  generic-applicable  to  a  variety  of  weapon  systems. 


DIAQN08TIC  IMPROVEMENT  PROaHAMS  ARE  UNDERWAY 


INTRODUCTION 


J 


HOW  CAN  THIS  QUIDS  HELP  YOU? 

Th«  outputs  from  many  of  tha  governmant-sponsored 
programs  ara  a  varlaty  of  taehniquas,  procaduras,  standards,  and 
davioas  which  oan  ba  applied  to  tha  acquisition  of  a  system's  diagnostic 
capability.  However,  this  type  of  Information  appears  In  a  varlaty  of 
reports,  military  standards,  specifications,  and  other  documents.  Tha 
major  focus  of  this  guide  Is  to  bring  together  this  knowledge  In  a  usable 
form  and  tie  this  to  the  various  diagnostic  activities  which  occur  during 
the  acquisition  and  deployment  of  a  weapon  system.  In  addition,  where 
holes  exist  in  this  acquisition  process,  the  guide  attempts  to  fill  them. 
Following  this  procedure  will  help  you  in  doing  a  better  job  of  designing  a 
weapon  system  diagnostic  capability. 

This  guide  Is  for  use  by  the  weapon  system  DB8IQNBR--  to 
help  him  understand  the  relationship  of  the  design  of  the  diagnostic 
capability  to  the  prime  system  itself  and  to  provide  detailed  methods, 
procedures,  tools,  and  trade«off  information  which  can  be  applied  to  the 
design  and  demonstration  of  the  weapon  system's  diagnostic  capability. 

This  guide  provides  the  user  with  a  thorough  compilation  of 
available  testability/diagnostic  design  Information. 

This  guide  Is  the  last  of  three  documents.  The  first  two  are  for 
use  by  the  Qovemment  and  Contractor  Program  Managers,  respectively. 


THhll  QUIDie  •  ONI  FON  lACH  TYPE  OP  USU.  THIS  ONI  IS 

PON  TNI  DISIQNIR 

DERNmONS 


WHAT  DO  WE  MEAN  BY  INTEQRATED  DIAGNOSTICS? 

Btfort  using  this  guide  It  is  impsrstivs  that  you  understand  the 
definition  of  a  few  words.  The  first  term  Is  'testability”,  which  is  defined 
as  ”a  design  characteristic  which  allows  the  status  of  tiie  unit  to  be 
confidently  determined  In  a  timely  manner.”  It  Includes  the  capability  to 
detect.  Isolate  failures  and  minimize  false  alarms.  Therefore,  testability 
may  be  regarded  as  Inherent  to  the  item's  design. 

"DIagnoatIca”  la  defined  as  ”the  hardware,  software  and/or  other 
documented  means  used  tc  determine  a  malfunction  has  occurred  and 
to  isolate  the  cause  of  the  malfunction.”  It  also  refers  to  "the  action  of 
detecting  and  Isolating  failures.” 

"Integrated  diagnoatlos"  Is  defined  as  a  'structured  design  and 
management  prooeas  to  achieve  the  maximum  effectivenaas  of  a 
weapon  system's  diagnostic  capability  by  considering  and  Integrating  all 
related  pertinent  diagnostic  elements.”  The  process  Includes  Interfaces 
between  design,  engineering,  testability,  reliability,  maintainability, 
human  engineering,  and  logistic  support  analysis.  The  goal  Is  a  cost* 
effective  capability  to  detect  and  unambiguously  Isolate  all  faults  known 
or  expected  to  occur  In  weapon  systems  and  equipment  In  order  to 
satisfy  weapon  system  mission  requirements. 

"DIagnoatIo  capability"  refers  to  the  capability  of  the  system  to  detect 
and  Isolate  faults,  utilizing  automatic  and  manual  testing,  maintenance 
aids,  technical  Infomiation  and  the  effects  of  personnel  and  training. 

"DIagnoatIc  element"  Is  defined  as  one  part  of  the  diagnostic  capability 
(e.  g.,  ATE). 

"DIagnoatIc  Subsystem"  is  defined  as  all  the  diagnostic  elements 
which  constitute  a  weapon  system’s  diagnostic  capability. 

"Embedded  diagnostics"  Is  defined  as  any  portion  of  the  weapon 
system's  diagnostic  capability  which  is  an  Integral  part  of  the  prime 
system  or  support  system.  "Integral”  Implies  that  the  embedded  portion 
Is  physically  enclosed  In  the  prime  system  and/or  permanently  attached- 
-physically  or  electrically. 


-XV- 


DERNmONS 


"ExUrnal  diagnoatloa'*  Is  defined  as  any  portion  of  the  vyeapon 
system’s  diagnostic  capability  which  is  not  embedded. 

It  Is  Important  to  understand  that  Integrated  diagnostics  is  a  structured 
process  for  acquiring  a  diagnostic  capability. 


HOW  TO  USE  THIS  GUIDE 


For  a  better  understanding  of  the  various  diagnostic  activities 
that  take  place  during  the  acquisition  and  deployment  of  a  weapon 
system,  a  Roadmap  has  been  prepared  for  your  use.  The  Roadmap 
depicts  all  of  the  diagnostic  activities  that  take  place  during  each  phase 
of  weapon  system  acquisition  and  deployment.  The  Roadmap  Is  shown 
In  Figure  1  (located  at  the  end  of  this  section),  with  Inputs  and  outputs 
for  each  activity.  This  Roadmap  gives  the  reader  the  entire  picture  of 
diagnostic  activities  from  beginning  to  end.  It  Is  recognized  that  there  Is 
no  single  Roadmap  that  can  apply  to  all  situations.  Thus  the  Roadmap 
Is  designed  with  multiple  entry  points  to  provide  flexibility. 


THE  ROADMAP  QtVBS  YOU  THE  BIQ  PICTURE 


The  structure  of  the  guide  is  built  around  this  Roadmap.  The 
following  seven  requirements  were  established  which  apply  to  the 
Roadmap  activities.  These  requirements  are  listed  In  Table  1 . 

Reference  to  a  specific  requirement  Is  shown  on  the 
Roadmap,  so  the  reader  can  quickly  relate  a  diagnostic  activity  on  the 
Roadmap  to  specific  guidance  Information  contained  In  this  guide. 


HOW  TO  USE  THIS  GUIDE 


TABLE  1.  ESTABLISHED  REQUIREMENTS 


REQUIREMENT# 

REQUIREMENT 

1 

BSTABLISHINQ  AND  JUSTIPYINO  A  PROGRAM 

FOR  ACQUIRING  A  DIAGNOSTIC  CAPABILITY 

2 

ESTABLISHING  AND  AUOCATINQ  DIAGNOSTIC 
REQUIREMENTS 

3 

rfiSi^'tNING  THE  DIAGNOSTIC  CAPABILITY 

4 

AHAI  '.*818  AND  ASSESSMENT  OF  THE  PERFORMANCE 

OF  THE  DIAGNOSTIC  CAPABILITY 

5 

CONDUCTING  DESIGN  REVIEWS 

a 

CONDUCTING  TEST  AND  EVALUATION 

7 

MATURATION  OF  THE  DIAGNOSTIC  CAPABILITY 

Each  on«  of  thtso  btslo  roquiromontt  It  foliowod  by  dotalltd 
rtquirtmtnti  (•.  g.,  Roquirtmtnt  3.1.  Providing  a  Cohailva  Dlagnoitlo 
Datign  Prooatt).  Eaoh  of  thaia  datallad  roquiromontt  It  tiod  to  a 
woapon  tyttom  activity  and  a  woapon  tyttom  aoquititlon  phato. 

Tht  throo  guldot  aro  ttruoturod  in  ottontlally  tho  tamo  way* 
•tho  difforonoo  boing  tho  guidanoo  matorlal  tuppllod  la  tallortd  for  tht 
USER  of  oaoh  tpociflo  guldo.  Each  roquiromonf  la  highllghtod  for  oaay 
aoooaa  to  tho  Information  tho  uaor  requirot. 

Each  of  tho  guldot  containt  a  Loaaont  Loarnod  Appondlx 
(Appondix  A),  which  will  holp  tho  utor  to  undorttand  how  thia  guidanoo 
Information  can  bo  appllod  to  roal-world  aoqulaltlona.  Appondlx  B  llati 
tho  Aoronymt  utod. 


WHAT’S  DIFFERENT  ABOUT  THIS  QUIOp  AS  OPPOSED  TO 
THE  OTHER  TWO? 
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HOW  TO  USE  THIS  GUIDE 


It  It  rtcogniztd  that  tht  dtslgnvr  of  tht  diagnostic  capability 
has  a  vital  Interest  In  several  of  the  seven  requirements  Hated  In  Table  1 
and  very  little  Interest  In  the  others.  The  information  contained  lelative  to 
Requirement  #'s  3  and  4  Is  supplemented  by  Appendices  C,  D,  and  E.  It 
Is  Important  for  the  user  of  this  guide  to  refer  to  these  appendices, 
because  they  contain  Information  on  the  techniques  and  tools  which  can 
assist  the  user.  Appendix  C  not  only  describes  tools  (both  automatic  and 
manual)  which  can  assist  In  performing  the  design  activities  under 
Requirement  #'s  3  and  4,  but  also  addresses  tools  which  are  applicable 
to  other  requirements.  As  shown  in  Table  2,  these  tools  are  categorized 
by  the  requirement  to  which  they  apply.  However,  some  tools  apply  to 
more  than  one  requirement  (e.g.,  a  design  tool  can  also  be  used  to 
assess  the  design).  In  those  oases,  the  guide  Identifies  Its  primary  and 
secondary  use. 


TABLES.  CATEGORIES  OF  TOOL  TYPES 


MQUIMMINT  (PMOM  TAIL1 1) 

•  tISTASUSHINa 
aiQUIMMINTS 

ItOISKM 

0  4  AIMSSMINT 

4  7MATUMTI0N 

ssranaom 

0  0«>tlMUMT10NOAMU( 

0  N«(ANM.Vra 

0  tVKriM  «MM«TUTVMI 

M.,  MminONItM, 

TMNANOtl 

0  NMNMAM* 

PMOTnU 

0  oiAaNotTNMnrmwNa 

IM.  mMNMTIO  inMTiaY, 
ntr/OMOMOtTW  WMVMneM, 
TIVUMMI  MTOMMATMN 
AUTMOMNO,  MOOf  ■  4 

VnOT* 

tn..  I*AUITMMUUTI0M,IIT 

imomiNiM) 

0  UAMTMNAIH.rTY  MMONITMTON 

0  nilMAOKANAlVtW 
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THI OUIDB 18  STBUCTUniD  TO  QIV8  TH8  U8B8  BA8Y  ACCB88  TO 
THB INFOBMATION  RBQUinBD 


It  Is  rsoognlzsd  that  a  gutda  of  this  type  cannot  contain  all  the 
necessary  Information  that  the  user  requires.  In  these  eases,  an  attempt 
has  been  made  to  cite  reference  documents,  such  as  military  standards, 
handbooks,  and  reports. 


AN  AUTOMATBD  VBRWON  OF  THIS  QUIOANCB,  PLUS  80MB 
COMPUTBRIZBO  TOOLS  ARB  AVAILASLB 


To  aid  In  the  use  of  these  guides,  a  computerized.  Interactive 
version  of  all  three  guides  has  been  developed.  If  you  are  Interested  In 
obtaining  these  software  programs,  you  may  contact  Rome  Air 
Development  Center,  RADC/RBET,  Qrlffiss  Air  Force  Base,  New  York, 
13441-6700,  (telephone  number;  315/330-4726,  AV  587-4726). 
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VAUDATION 
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NouvamM  /  mi 


BO 


NouvanvA 


WEAPON  svsrai  ? 


PROGRAMMATIC 


REQUIREMENT 


eSTAILISHINQ  AND  JU8TIPYINQ  A  PROGRAM  FOR  ACQUIRING  A  DIAGNOSTIC 
CAPA8ILITY 

QYWYiyy 

DoO  organizallont  ara  oflan  diaappointad  at  tha 
ptrformanoa  of  a  waapon  ayatam'a  diagnottio  capability 
one#  It  is  daployad.  This  dlaappolntmant  oftan  rasults  In 
frustration  by  tha  usar,  an  advarsarlal  ralatlonship 
batwaan  tha  aoquirar  and  tha  produoar,  and  costly 
anginaaring  changas.  Tha  fact  Is  that  tha  quality  of  tha 
aoquirad  diagnostic  capability  Is  a  two*way  straat.  In 
tha  casa  of  tha  govammant,  caraful  consldaratlon  must 
ba  givan  to  what  you  want  tha  contractor  to  dallvar.  In 
tha  casa  of  tha  contractor,  ha  must  ba  dadicatad  to 
producing  a  quality  product.  Spacifying  fault  datactlon 
and  Isolation  raquiramants  Is  a  difficult,  complax  job  for 
tha  Govammant  Program  Managar.  Juatifying  his 
program  to  a  highar  authority  In  olaar,  oonclsa  tarms  Is 
assantlal.  Establishing  raallstio  and  faasibla  plans  for 
satisfying  thasa  raquiramants  Is  a  prlma  rasponalbllity  of 
tha  Contractor  Program  Managar.  Implamanting  thasa 
plans  Is  tha  rasponalbllity  of  tha  waapon  syatam 
dasignar.  Without  a  olaar  undarstanding  and  olosa 
oooparatlon  among  thasa  paopla,  production  of  a  lass- 
than<satlsfaotory  diagnostic  capability  Is  Inavltabla. 


Rwmti 

1.1  Ravlaw  tha  Statamant  of  Naad  (SON)  to  aaaura  a  elaar  undaratanding  of 
tha  baala  for  tha  davalopmant  program. 

1.2  DlagnoaUo  oonaldaratlona  ora  a  vary  Important  part  of  your  proposal. 

1.3  TIa  diagnostic  capability  plana  to  tha  ayatam  anginaaring  plana. 

1.4  MaKa  aura  that  opaclflo  Information  on  diagnostic  and  capability  Issues 
ara  avallabla  for  Inclusion  In  SCPa  and  DCPa. 
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REVIEWING  A  STATEMENT  OF  NEED 


REQUIREMENT  #1.1 


CVTOJ  OPER.  concept  DEM/ 

acqSe 


WEAPON 

STSTEM 

ACTIVrriES 


PROD/ 

DEPL. 


RFP 

PREP 


RFP 

PREP 


RFP 

PREP 


DIAGNOSTIC 

ACTIVrTIES 


SON  REVIEWED 


DiAQNOeTlC  ACTIVITY 

Th«  major  sonaldtrallon  In  tho  Initiation  of  a  vvaapon  ayatam  aoquialtlon 
program  la  tha  praparatlon  of  a  Statamant  of  Naad.  Each  of  tha  aarvicaa  haa  Ita  own 
daaignation  for  thia  dooumant.  For  a  major  waapon  ayatam,  DoD  Inatruotlon  6000.2 
daaignataa  thIa  dooumant  aa  a  *Mlaalon«Naad  Statamant  (MNS)."  For  laaa*than-major 
ayatama,  tha  aarvloaa  uaa  othar  tarma,  auoh  aa  *Oparatlonal  Raquiramanta  Dooumant" 
and  "Raquirad  Oparatlonai  Capabitity."  It  la  Important  that  thaaa  dooumanta  ra*'  'ot  thaaa 
oparatlonal  raquiramanta  In  tarma  whiofi  can  ba  proparfy  Intarpratad  to  produoa  diagnoatio 
raquIramanta.Tha  oontraotor  la  not  Involvad  in  tha  ganaratlon  of  thia  dooumant  but  muat 
ba  awara  of  It'a  oontant  alnoa  It  forma  tha  baaalina  upon  which  tha  diagnoatio 
raquiramanta  ara  darfvad. 

PWQCIDUM 

Each  of  tha  military  aarvloaa  haa  iaauad  policy  dlractlvan  and  guldancn  relating 
to  tha  praparatlon  of  a  Statamant  of  Naad  (SON).  DoD  Inatruotlon  5000.2  dallnaataa  tha 
format  for  an  MNS.  Thia  format  doaa  not  differ  appreciably  from  tha  formate  uaad  for  laaa- 
than-major  new  atarta,  thua  tha  following  guidance  will  ba  dlacuaaad  In  relation  to  the 
MNS. 

Tha  SON  la  Iaauad  prior  to  Concept  Exploration.  Whan  tha  Concept 
Exploration  Phaaa  la  not  conducted,  tha  SON  ahould  ba  Iaauad  prior  to  initiation  of  work. 
In  addition,  tha  validity  of  tha  SON  can  ba  reevaluated  prior  to  the  Initiation  of  Dem/Val, 
F8D,  and  Production. 
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REVIEWING  A  STATEMENT  OF  NEED 


REQUIREMENT  #1.1 


It  It  almott  at  Important  to  antura  what  should  not  ba  put  Into  an  SON  at  what 
should  ba  put  Into  an  SON.  From  a  dlagnostlo  point  of  vlaw.  Initially  thars  art  no 
dlagnoatio  raquiramants  par  ta,  only  raqulramanto  which  raflaot  a  thraat  and  mission  and 
oparatlonal  naads,  plua  oartain  constraints  put  on  tha  waapon  aystam,  such  as  rtsourca 
limitations.  At  tha  Initiation  of  a  waapon  aystam  davalopmant,  It  It  Important  that  tha 
Qovarnmant  Program  Managar  and  his  contractor  not  ba  llmitad  by  astabllshing 
pramatura  diagnostic  raquiramants,  such  as  a  oartain  paroant  fault  dataotlorVtauN  Isolation 
to  a  givan  unit,  or  an  MTTR.  Rathar,  tha  contractor  should  ba  givan  tha  flaxiblllty  to  darlva 
tha  diagnostic  raquiramants  from  mission  naads,  such  as  sortia  rates,  mobility 
raquiramants,  and  tha  mission  scanarto. 

Tha  daaignar's  intarast  Is  mainly  eantarad  on  tha  oontant  of  tha  waapon 
systsm's  spadflcatlon  and  not  tha  SON.  Howavar,  it  may  prova  usaful  for  tha  dasignar  to 
raviaw  tha  SON  to  fadlHata  an  undarstanding  of  tha  basis  for  tha  spadflcatlon. 


REVIEWING  A  STATEMENT  OF  NEED 


REQUIREMENT  #1.1 


T 
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RESPONDING  TO  AN  RFP,  SOW.  SPECIFICATION  REQUIREMENT  #1.2 


WEAPON 
SYSTEM 
ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL. 

WEAPON 

SYSTEM 

ACTIVnY 

A  A  A  A 

CONTRACT  AWARD 

DIAGNOSTIC 

ACTIVmES 

ZS  71  H  71 

DIAGNOSTIC  INPUTS  TO  RFP/SOW/SPEC 

DIAGNOSTIC  ACTIVITY 

Cl«ar,  ooncisa,  and  faaalbit  provisions  must  be  Inserted  Into  the  Request  tor 
Proposal,  the  Statement  of  Work,  end  the  System  Speolfloatlon,  as  a  means  for  assuring 
that  the  contractor  and  his  subcontractors  have  a  clear  understanding  of  <^hat  Is  required 
of  the  diagnostic  capability. 

PR9.CBBWJB 

One  of  the  Initial  tasks  which  must  be  undertaken  by  the  Government  Program 
Manager,  at  the  beginning  of  each  acquisition  phase,  Is  the  development  of  the  Request 
for  Proposal,  which  will  subsequently  lead  to  a  contractual  document.  For  the  Concept 
Exploration  Phase,  normally  the  RFP  contains  a  Statement  of  Work  without  an  associated 
weapon  system  specification.  The  specification  Is  normally  Invoked  no  sooner  than  the 
Demonstration  and  Validation  Phase,  it  Is  normally  written  by  the  contractor,  with  final 
review  by  the  Government  Program  Manager.  The  requirements  for  this  diagnostic 
capability  must  appear  In  a  variety  of  places  throughout  these  documents  to  assure  the 
acquisition  of  a  satisfactory  diagnostic  capability.  For  the  Concept  Exploration  Phase, 
these  requirements  are  general  in  nature  and  allow  the  maximum  flexibility  for  the 
contractor  to  do  his  Job.  As  the  weapon  system  design  proceeds,  these  requirements 
become  more  and  more  specific.  The  thrust  and  content  of  the  provisions  contained  In 
these  documents  vary,  depending  on  the  acquisition  strategy  developed  by  the 
Government  Program  Manager,  the  phase  In  which  these  documents  are  Invoked,  and 
the  size  and  complexity  of  the  weapon  system. 
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RESPONDING  TO  AN  RFP,  SOW,  SPECIFICATION 


REQUIREMENT  #1.2 


Although  th«  bulk  of  the  guidance  on  the  preparation  of  these  documents, 
which  follows,  Is  for  the  Government  and  Contractor  Program  Managers,  It  Is  Included  In 
this  guide  for  the  following  reasons: 

1.  To  promote  understanding  with  the  designer  on  how  to  address  diagnostic 
requirements. 

2.  To  provide  Information  to  contractors  In  their  review  of  draft  RFPs/SOWs 
and  Specifications. 

3.  To  provide  Insight  to  the  contractor  In  the  preparation  of  the  diagnostic 
portions  of  his  proposals. 

QUIDAHCE 

No  guidance  on  the  content  and  form  of  what  should  be  Included  In  an  RFP  and 
System  Specifloatlon  can  be  made,  which  is  applicable  to  every  system  or  equipment. 
Thus  the  Information  which  follows  must  be  perceived  as  examples  of  how  to  best  specify 
a  weapon  system's  diagnostio  capability.  Tailoring  is  a  must. 


RE8PONDINQ  TO  AN  RPP: 

Diagnostics  Impacts  a  number  of  sections  within  an  RFP,  as  shown  In  the 
following  paragraphs. 

Special  .fontraet  Requirements  (Section  H)  •  Contractor  incentives  and  warranties  ars 
contained  In  this  section  of  the  RFP.  The  type  and  content  of  these  Incentives  and 
warranties  are  almost  limitless,  depending  on  the  innovation  of  the  RFP  writer. 

Instructlcna  to  Offerors  (Section  L)  •  Emphasis  must  be  placed  on  Introduoing  the 
concept  of  Integrated  dlagnosUoa.  Although  no  standard  format  exists  for  this  section  of 
the  RFP,  this  section  must  address  the  need  for  managerial  and  technical  Information 
relative  to  Integrated  diagnostics  and  the  meeting  of  the  diagnostic  requirements. 
Explanation  la  required  so  that  the  contractor  understands  that  Integrated  diagnostics 
Interfaces  with  logistics,  reliability,  maintainability,  testability,  human  engineering,  and 
safety  requirements. 

Automation  of  the  diagnostic  design  process  should  be  addressed,  because  It 
can  provide  for  a  more  efficient  and  effective  design  process.  It  Is  not  the  government's 
job  to  dictate  the  use  of  these  design  tools,  but  rather  to  encourage  their  use.  This  can  be 
accomplished  by  adding  provisions  to  the  Instructions  to  Offerors  relating  to: 
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0  A  discussion  of  d'tsign  aids  which  will  facilitate  the  design  and  integration  of 
the  diagnostic  capability  Into  the  system  engineering  process 

0  The  development  and  use  of  a  diagnostic  data  base  which  supports  the 
application  of  these  tools 

o  Identification  of  how  automation  will  reduce  risk  In  the  design  of  the 
diagnostic  capability 

0  Means  for  providing  the  government  with  appropriate  documentation  for 
U’  derstanding  and  validating  ^e  output  of  the  automation  process 

0  Additional  information  on  motivating  the  contractor  to  utilize  automation  In 
the  diagnostic  design  process  is  Included  In  the  Computer*Alded  Acquisition 
and  Logistic  Support  (CALS)  Implementation  Guide.  MIL-HDBK‘59.  Copies 
can  be  obtained  from  the  CALS  Policy  Office,  Office  of  the  Secretary  of 
Defense.  Included  in  this  guide  are  means  for  tailoring  CDRLs  and  DIDs  to 
encourage  the  use  of  design  automation. 

Evaluation  Faetora  for  Award  (Section  M)  -  This  section  will  likely  be  written  to  assure 
that  the  proposal  writer  understands  that  Integrated  diagnostics  and  diagnostic 
requirements  will  have  a  significant  impact  on  the  selection  of  a  contractor.  The 
evaluation  factors  reflect  the  diagnostic  content  of  the  Instructions  to  Offerors  (Section  L) 
from  both  technical  and  management  points  of  view.  Thus  the  recognKlon  thet  integrated 
diagnostics  Is  part  of  the  system  engineering  process  must  be  described  In  this  section, 
along  with  the  ability  to  utilize  advanced  technology  In  solving  this  problem.  From  a 
management  viewpoint,  the  evaluation  normally  will  emphasize  the  need  for  a  single 
person  being  responsible  for  the  entire  diagnostic  capability,  often  requiring  a  person  full¬ 
time. 

In  addition  to  having  the  evaluation  factors  reflect  the  content  of  the  Instructions 
to  Offerors,  several  other  evaluation  factors  are  of  Importance.  These  Include: 

0  The  amount  and  type  of  specialized  education  and  training  given  to  both 
contractor  program  managers  and  designers  which  relate  to  testability  and 
Integrated  diagnostics 

0  The  Independent  research  and  development  conducted  by  the  contractor 
which  relates  to  teatabiiity  and  diagnostic  design  tool  development  and 
integrated  diagnostics  demonstrations 
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RESPONDING  TO  A  STATEMENT  OF  WORK 

The  Statement  of  Work  vartee,  depending  on  which  weapon  system  acquisition 
phase  Is  being  addressed.  Four  sample  Statements  of  Work  •  one  each  for  Concept 
Exploration,  Demonstration  and  Validation,  Full-Scale  Development,  and  Production  are 
contained  in  the  Contractoi  Program  Manager's  Guide.  The  principal  attributes  of  these 
Statements  of  Work  are: 

1 .  An  engineering  analysis  (including  gathering  of  field  data)  from  a  previously 
fielded  weapon  system(s)  to  determine  diagnostic  capability  performance 
deficiencies  experienced 

2.  Identification  of  specific  risk  areas  which  require  design  attention 

3.  A  requirement  for  preparation  and  Implementation  of  a  Diagnostic  Capability 
Maturation  Plan,  including  assets  required,  activities  required,  and  data 
collection 

4.  Thorough  analysis  of  the  design  of  the  embedded  diagnostics  to  be 
completed  by  CDR 

5.  Design  analysis  and  specification  of  the  external  diagnostic  capability, 
Including  overlap,  by  COR 

6.  A  requirement  for  demonstration  of  the  diagnostic  capability,  Including  a 
thorough,  statistically  valid  sample  in  selected  areas  of  the  system. 

PREPARING  A  SPEaPICATION: 

Preparation  of  the  diagnostic  portion  of  a  weapon  system  specification  Is  a  Job 
whicfi  necessitates  a  full  understanding  of  the  design  and  fielding  of  the  diagnostic 
capability.  There  le  a  lack  of  agreement  on  a  standard  methodology  for  this  speoifioatlon. 
The  contractor  must  recognize  the  intricacies  of  this  job  to  ensure  that  the  specifications 
utilized  to  acquire  a  weapon  system  clearly  define  the  diagnostic  requirements. 

What  Is  a  Failure? 

An  initial  requirement  in  the  specification  Is  to  establish  the  definition  of  a  failure 
at  system,  subsystem,  and  unit  levels.  This  requirement  Is  essential  In  demonstrating 
graceful  degradation  through  the  use  of  fault-tolerant  design,  reconfigurability, 
redundancy,  and  performance  monitoring.  A  failure  may  be  defined  In  a  number  of  ways, 
depending  on  the  mission  to  be  performed,  it  may  be  defined  as  causing  the  mission  and 
performance  requirements  of  the  prime  system  to  be  compromised. 


MO 
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What  Maana  art  Avallabla  to  Parform  Dlagnoatlca? 

Too  often  the  word  "dlagnoatlo”  Is  used  Interchangeably  with  "test."  The 
specification  must  recognize  the  different  types  of  diagnostics,  which  Include: 

0  Visual  observations  (e.g.,  the  display  isn’t  working) 

0  Symptomatic  (e.g.,  the  case  Is  too  hot) 

0  Test  (e.g.,  a  voHage  Is  out  of  spec.). 

Means  through  which  systems'  diagnostics  can  be  addressed  Include: 

0  Automatic  testing  (I.e.,  embedded  or  external) 

0  Manual  troubleshooting,  utilizing  technical  manuals,  troubleshooting 
procedures,  manual  teat  equipment 

0  Operator  and  maintenance  technicians'  observations  and  various  forms  of 
performance  monitoring 

0  A  combination  of  the  above. 

What  Terma  Can  be  Used  In  Specifying  DIagnoatle  Requirements? 

As  Indicated  previously,  various  terms  may  be  used  to  specify  diagnostic 
requirements.  A  preferred  set  Is  contained  In  an  RADC  report.  "A  Rationale  and 
Approach  for  Defining  and  Structuring  Testability  Requirements,”  (RADC'TR<85*150), 
August  1985.  The  set  includes  the  following  terms.  Additional  terms,  along  with 
techniques  for  verification  are  contained  In  an  RADC  report,  ”BIT/Extemal  Test  Figures  of 
Merit  and  Demonstration  Techniques",  (RADC*TR-79-309). 

Fraction  of  Faults  Dateoted  (PFD) 

FFD  can  be  defined  as  that  fraction  of  failures  which  occur  over  operating 
time  which  can  be  correctly  identified  through  direct  observation  or  other  specified  means 
by  an  operator  and/or  other  specified  personnel  under  a  given  set  of  conditions.  The 
quantitative  definition  of  FFD  is: 
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FFD  -  Fq 


Fa 

Wh«r*: 

»  Number  of  aotual  ftlluraa  (faults)  which  (will) 
occur  ovar  operating  tima,  T. 

Fq  m  Number  of  actual  failures  correctly  Identified 
through  direct  observation  and  other  specified 
means  by  an  operator  and/or  other  specified 
personnel  under  a  given  set(s)  of  conditions. 

In  specifying  FFD,  all  tfie  various  means  which  can  be  used  to  detect  faults 
must  bo  taken  Into  consideration.  The  requirement  for  FFD  should  be  stringent  enough  to 
exclude  the  application  of  the  types  of  detection  means  which  are 
unsatisfaotory/unaoceptable  for  the  system  needs/ob)eotlvos/phlloeophles,  but  flexible 
enough  to  allow  the  contractor  to  tailor  his  design  cost  effectively.  In  general,  the  specific 
nature  and  mix  of  the  meane  to  be  employed  to  achieve  a  given  minimum  FFD  should  be 
dependent  on  results  of  an  analysis  of  each  such  aitemative  and  Its  cost  and  performance 
effectiveness,  In  conjunction  with  other  system/equipment  design  factors  and 
requirements.  The  contractor  should  be  tasked  to  perform  such  analyses  and  provide 
resuHs/recommc.'idatlons  to  the  procuring  aotMty  baaed  on  theae  factors. 

The  FFD  specification  parameter  must  be  specifically  defined  to  take  Into 
account  frequency  of  failure  (failure  rates)  of  the  components  making  up  the  system.  It  is 
only  In  this  way  that  FFD  will  be  representative  of  wrtiat  occurs  during  operational  (He. 

In  specifying  FFD,  care  must  be  taken  to  define  that  set  of  detection  conditions 
which  are  acceptable;  for  example,  who  can  perform  the  detection  function;  what  are  the 
acceptable  means  through  which  detection  can  be  performed;  during  which  equipment 
status  modes  can  detection  be  performed  (operation,  pre*  or  post«mlaslon  checks,  etc.); 
and  whether  or  not  a  failurs  must  be  detected  within  a  certain  period  of  time? 

Fraction  of  Faults  Isolated  (FFI) 

FFI  can  be  defined  as  that  fraction  of  failures  which  occur  over  operating  time 
which  can  be  correctly  Isolated  to  x  units,  or  fewer,  at  a  given  maintenance  echelon 
through  use  of  specified  means,  by  a  maintenance  technician  or  other  specified 
personnel.  Tlie  quantitative  definition  for  FFI  is: 
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FFI .  F| 

Wh«r«: 

Fy(^  ■  Number  of  actual  fallurta  (faults)  which  (will) 
occur  over  operating  tima  T. 

F|  >  Number  of  actual  failures  (faults)  which  (will) 
occur  over  operating  time  T  that  can  be  correctly 
Isolated  to  x  units,  or  fewer,  at  a  given  maintenance 
echelon  through  use  of  specified  diagnostic  sohame(8)/ 
procedura(8)  (or  a  defined  sat  of  such),  by  a 
maintenance  technician  or  other  spaciflad  parsonnei. 

In  specifying  FFI,  all  the  various  generic  means  acceptable  In  general  for  the 
misalon/operatlonal/maintenanoe  environment  which  can  be  used  to  Isolate  faults  must  be 
taken  Into  consideration.  The  requirement  for  FFI  should  be  stringent  enough  to  exclude 
the  application  of  Isolation  means  which  are  known  In  general  to  be. 
uneatlafaotory/unacoeptable  to  the  system  needs/malntenance  phllosophy/obleotives  but 
are  flexible  enough  to  allow  the  contractor  to  tailor  his  design  cost  effectively.  The  specific 
nature  and  mix  of  the  means  to  be  employed  should  be  dependent  on  the  results  of  an 
analysis  task  (levied  on,  and  performed  by,  the  contractor)  of  each  fault  liolatlon 
alternative.  In  conjunction  with  syatem/equipment  design  factors,  maintainability 
requirements,  and  support  system  needs.  Generally  speaking,  unless  there  Is  clear 
evidence  that  unacceptable  weight,  volume,  or  uost  penalties  would  accrue,  primary 
diagnostic  means  based  on:  (1)  signal  tracing  and  analyses  through  the  use  of 
schematics  and  test  equipment,  and  (2)  repetitive  Item  remove/replaeement/performanoe 
check  actions  should  be  avoided. 

In  specifying  FFI,  care  must  be  taken  to  Indicate  the  conditions  under  which 
Isolation  must  take  place: 

o  Where  it  takes  place  (i.e.,  Organizatbnal  Level,  Shop  Level) 

0  What  are  the  acceptable  means  of  Isolation  (I.e.,  built-in  test,  external 
testers,  general-purpose  testers,  peculiar  testers,  manual  means,  degree  of 
manual  means) 

0  Who  will  perform  the  Isolation  (I.e.,  operator  or  maintenance  technician) 

0  Its  constraints  (I.e.,  prohibition  of  wholesale  removal  of  units,  time  allowable) 
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0  Its  sseond  Isolation  tisr  raquiramants  (what  happans  aftar  Isolation  to  propar 
ambiguity  lava!) 

0  Ths  tima  constraints  lavlad  by  tha  maintainability  rsqulramant. 

Ths  FFI  paramatar  must  ba  spaoltloally  daflnad  to  taka  Into  account  Iraquancy 
of  fallura  (fallura  ratas)  of  tha  componants  making  up  tha  aystam.  It  Is  only  In  this  way 
that  FFI  will  ba  raprassntativa  of  what  occurs  during  operational  Ufa. 

Falaa  Alarm  Rata 

A  falsa  alarm  Is  daflnad  as  an  apparent  Indication  of  fallura  whan,  In  fact,  no 
failure  exists.  Tha  falsa  alarm  rata  is  tha  number  of  falsa  alarms  par  unit  of  time. 

Intermittent  faults  can  ba  difficult  to  distinguish  from  falsa  alarms  during 
operational  tost  and  In  use.  A  properly  structured  qualification  test,  however,  can  exclude 
tha  influanoa  of  Intarmittant  faults. 

Falsa  alarm  rates  are  conlrollabla  through  tha  use  of  such  design  techniques 

and  features  as; 

0  Scope  and  magnitude  of  performance  monitoring 

0  Definition  of  test  tolerances 

0  Transient  monitoring  and  oontrol 

0  Multiple-run  decision  logic 

0  Environmental  affects  fUterlng  and  Idantlfloation. 

Fraction  of  Brreneoua  FauR  leolatton  Reeulte  (FEIR) 

FEFI  Is  the  fraction  of  BIT  or  axtamai  taatar  isolations  that  Identify  tha  wrong 
removable  unit  (subunit)  or  group  of  units  (subunits)  as  failed.  FEFI  Is  primarily  a  design 
problem  resulting  either  from  test  system  design  error  or  low  sensitivity  thresholds  and 
tolerance  levels  cf  system/equipment  oomponente  and/or  signals.  It  can  have  serious 
oonsequenoes  by  creating  confusion  during  fault  iaolation  and  by  eroding  maintenance 
technician  confidence  In  the  test  system.  The  quantitative  definition  Is; 
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FEFI  -  Fg 


Wh«r«; 

F^  «  Number  of  actual  falluraa  (faults)  which  (will) 
occur  ovar  oparating  tima  T. 

Fe  ■  Numbar  of  actual  falluras  (faults)  which  (will) 
occur  ovar  tIma  T  that  ara  iaoiatad  to  a 
nonfaliad  unit  or  group  of  units. 

What  Doaa  100%  Fault  Dataetlon/Fault  Isolation  Maan? 

In  dafining  FFD  aa  a  contractual  raquiramant  for  moat  programs,  M  la  aomatimaa 
•Implar  to  axcluda  thoaa  typaa  of  diraot  dataotlon  maana  (for  axampla,  datactlon  through 
tha  uaa  of  taohniclana)  which  would,  In  ganaral,  ba  unaatlafaotory  to  a  givan  mlaalon 
anvironmant  than  to  dafina  thoaa  that  ara  acoaptabla,  Tha  fact  that  an  FFD  raquiramant 
Is  Impoaad  should  not  Imply  that  100%  of  all  axpaotad  falluras  should  not  ba  dataotabia. 
Tha  contractor  should  ba  taakad  with  tha  davalopmant  of  ooat*affaotiva,  dafinad 
procaduraa  to  datact  all  axpactad  falluras.  All  of  thaaa,  howavar,  naad  not  ba  diraot 
maana  or  balong  to  tha  typa  of  diraot  maana  which  ara  dafinad  as  satisfactory  for  ganaral 
mlaalon  oparational  uaa,  providad  maintainability  and  othar  raqulramants  can  still  ba  mat. 
Datactlon  oan  Include  direct  or  Indirect  Indloatlona  to  an  operator,  tha  uaa  of  maintananoa 
taohniclana  or  othar  parsonnal  performing  In  acoordanea  with  a  aarlas  of  dafinad  routines, 
or  soma  combination  of  thaaa. 

For  FFI  100%  coverage  la  required,  which  aimply  atataa  that  using  a 
combination  of  all  diagnostic  raaouroas,  all  faults  oan  ba  Isolated,  given  an  adequate 
amount  of  time.  Applying  restrictions  In  tima  means  that  100%  of  all  axoactadJauIttJwm 
ba  laolatabla.  but  a  certain  fraction  (1  -FFh  mav  have  ambloulty  lavalt  grifttar  thinJhtt 

value  stated  or  ba  leolatabla  through  means  which  ara  definable,  but  which  do  not.tetlang 

to  tha  class  of  diagnostic  means  cited  as  balno  acceptable  for  ganaral  utaJn  th.t.glYtQ 
mission  or  use  anvironmant.  Consideration  must  ba  given  as  to  how  -^nd  where  Isolation 
to  tha  faulty  unlt(8)  must  taka  place. 

In  summary,  specifications  should  Indicate  a  1 00%  fault  dataction/fault  Isolation 
coverage  at  each  maintenance  level  (a.g.,  combinations  of  automatic  and  manual 
troubleshooting  m  .4(18  should  equal  100%).  This  doss  not  maan  that  100%  of  faults  can 
ba  Isolated  to  a  given  unit  within  a  given  tima  using  specific  diagnostic  resources. 


I 
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Wtwt  Is  DIagnottIo  Qrowth? 

Anothsr  ispsct  whioh  18  rsoommsndtd  to  bs  Introduof  d  It  that  of  diagnostic 
growth-similar  In  conospt  to  ths  airsady  astabllshad  rtllablllty  growth.  This  growth 
raquiromant  Is  asptolally  Important  In  ths  maturation  of  ths  systsm.  FIgurs  2  Is  a 
oonesptual  vsrslon  of  this  growth  proosss.  Dsmonstratlons  that  thsss  goals,  or 
rsquirsmsnts,  havs  bssn  aohlsvsd  at  varloua  phasss  of  wsapon  aystsm  dsvsiopmsnt 
must  bs  tallorsd  to  ths  spselfic  wsapon  systsm  acquisition  strategy.  For  Instanos.  If  ths 
psrformancs  of  an  aircraft  la  to  bs  svaluatsd  at  ths  conclusion  of  Dsm/Val,  then  ths  sntirs 
diagnostic  capability  for  ths  aircraft  should  reach  ths  specified  requirement  at  that  point  In 
time.  On  ths  other  hand,  If  only  specific  units  (usually  high  risk)  of  a  wsapon  systsm  are 
developed  during  Dsm/Val,  then  ths  diagnostic  capability  for  that  spsolflo  unit  may  bs 
demonstrated.  Ths  maturation  of  a  diagnostic  capability  for  ths  sntirs  wsapon  systsm.  In 
moat  oases,  will  extend  Into  ths  Deployment  Phase. 


OOM.  OOM.  OOAL  OQM. 


FIOURC2.  DIAONOSne  OPOWTH  CONCEPT 
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What  Doaa  a  '*Dlaonoatlc  Spaelfleatlon”  Contain? 

Tha  dlagnoatlo  portiont  of  tha  waapon  ayatam  apadfloation  diffar,  dtpandlng  on 
tha  ataga  of  davalopmant.  Normally,  thaaa  apaolfloationa  taka  tha  form  of  a  Prallmlnary 
Syatam  Spaolftoatlon,  raauKIng  from  Conoapt  Exploration;  a  Syatam  Spaolfloatlon,  darivad 
from  tha  Damonatratlon  and  Validation  Phaaa;  and  a  Configuration  Itam  Davalopmant 
Spaolfloatlon,  whioh  allooataa  raquiramanta  down  to  aubayatam  and  Itam  lavala,  (A  mora 
oomplata  dafinitlon  of  tha  varioua  typaa  of  apaolfloationa  la  eontalnad  In  MIL‘8TD*4gO, 
Spaolfloatlon  Praotloaa.)  Tha  following  axamptaa  of  dlagnoatlo  portlona  of  apaolfloationa 
follow  thia  form.  Tha  oontant  muat  ba  tallorad  to  fH  a  apa^  ayatam  raquiramant. 

Prallmlnary  Syatam  SpaeHleatlon 

Tha  Prallmlnary  Syatam  Spaolfloatlon  la  a  raauN  of  Conoapt  Exploration  Phaaa 
atudlaa,  prior  to  oonduoting  tha  datallad  dlagnoatto^atablllty  raquiramanta  analyala  during 
tha  Damonatratlon  and  Validation  Phaaa. 

Quantitativa  diagnoatlo/taatablllty  paramatara  ara  not  apaolflad  In  tha 
Prallmlnary  Syatam  Spaolfloatlon.  Rathar,  qualltativa  ayatam-laval  diagnoatlo/taatablllty 
goala  ara  Inoludad. 

Tha  modal  paragrapha  baiow  may  ba  Inoludad  In  tha  Prallmlnary  Syatam 
Spaolfloatlon  primarily  to  alart  tha  parforming  aotivlty  that  diagnoatioa/taatablllty  la 
oonaldarad  to  ba  an  Important  aapaot  of  tha  daaign  and  that  quantitativa  raquiramanta  will 
ba  Impoaad  In  tha  final  Syatam  Spaolfloatlon. 


9JCJC  Dtit|iNrT«laMaiy 

>XXI  NraMwIn  tkiB  U  piaiwii  to  pari, 

lh«  ■felMo  <•  •MaaviO  Matt  Mu 

SJt.XJ  T«X  Mao.  iMh  wM  waaiilM  hit*  mOMmI  t«l 

Maim  M  lalMraillf  Uaihfa  «r  Ml  MmOm  m4  MMaa. 

MXJ  a«ill.la  Tail.  MMm  «M«I  Ma«M  liaH  a«  awyima  ar 

a«IN«b.T«i(.  BIT  l»l»rM«M  Ml  b«  Ml  to  •^■Im  fMI 

itiMtiM/nilM  atom  caM-actorlallw.  BIT  Ui4laa(an  ibaU  a#  Bwlpita 

tor  toaUw  lilMltoii  ay  l■«l■^a^  yaraa— al  (atMralar/aatototoar). _ 

Syatam  Spaolfloatlon 

Quantitativa  diagnoatioa/taatablllty  raquiramanta  ara  darivad  from  tha  trada*off 
analyala  during  tha  Damonatratlon  and  Validation  Phaaa  and  ara  Inoorporatad  in  tha 
Syatam  Spaolfloatlon.  Raquiramanta  may  ba  axpraaaad  In  tarma  of  goala  and  thraaholda 
rathar  than  aa  a  aingla  numbar.  Raquiramanta  for  diagnoatioa/taatablllty  In  a  Syatam 
Spaolfloatlon  ara  providad  In  tha  following  modal. 


MODEL/SYSTEM  SPECinCATlON 


$.2.4.X  Ol9gno§ll»»n‘i»»hXHUty*Tlt§ _ (ln»§ft  naim) 

f  tl0»tgn«a  ter  teetatUlty  eng  eenetrueteg  te  permit  the  etetue  et  the 
eyeiem  ent  the  iinmhtgueue  loeetlen  et  teulte  te  be  eenthtently  aetenrUneg 

mnm  wWpPeWQ  m  V  WnWfy  fWmnPne 

9.t4,X.1  HrtMenIng  (Punetlenel  l/MMertty}  •  gyetemmubeyeteme  wHI  be 
pertttleneg  Inte  Line  tiepleeeeble  Unite  (Lttti)  beeed  on  the  tunetlen, 
minimum  erepthnem  number  etmtereonneeuene^  the  ebbity  le  leuh  leelete 
te  the  eeneel  unit  Ultle  will  be  eubdNMeblnle  next  level  repleeeebleimme 
(e.g.,  bhep  hepleeeeble  Unite,  or  bItU)  beeed  en  tunetlen,  minimum  or 
epbmum  number  et  Inlereenneetiene,  enb  the  ebmty  etpenennel  with  the 
ekieteuppert  equipment  tremint,  eng  teehnieelmenueleieteibtleeleie. 

reel  heinte  eng  Oenleete  •  root  peinte  eng  eenteete  ehell  be 
eenvenlently  leeeteg  eng  heve  eete  eeeeee  te  eignel  negee  eng  ehell  he 
previgeg  ter  the  meeeure  or  inleetlen  te  elmiheent  peremetere  ter  the 
purpeee  et  eveluehng  or  treubleeheeUng  the  elreult  meehenleme.  The 
number  eng  eheiee  et  eeeeeeible  negee  ehell  he  euthelent  te  ebiein  the 
equipment  teuh  geteebengeeleben  requlremente  Heteg  herein, 

3.i.4.X,S  Olegneetle  Oepeblllty  •  Per  eeeh  level  et  melnteneneei  ell 
glegneetle  reeeureee  ehell  be  Integreteg  te  previge  e  eeneletent  eng 
eemplete  glegneetle  eepehlllty.  A  eemplete  glegneetle  eepeblllty  muet 
Igentity  the  glegneetle  reeeureee  thel  will  be  ueeg  te  heve  tull  PDfPt 

pVrOTfffW  OTHI  WWW  WIV  flMHIIPfpWlOT  WpVw  wIflWi 

XM.AXe  bulfNn  Teel  •  guhHH  net  (btrjprevtelene  ehell  be  geelgneglnie 
the  eyeiem  le  loot  eyetem/equipment  eng  te  Interm  Mo 

epereteretgteebbllyetgieequqhnenttepeifemepertieMxmleelen, 

J.X.4.X.4.f  On-Line  BIT  Pertermenee  ttenlterlng  •  The  en-llne  BIT 
perfetmenee  menherlng  leeturee  eheX  be  eperebve  eng  eheh  previue  vebg 
pertermenee  ingleebene  prter  to  on4  gurt^  eperehen.  The  pertermenee 
menherlng  opoioOwi  ehell  be  eutemebe  eng  eenbnueue  engeheXt 

1.  Bneure  eubeyeteme  ere  eperetlenel  eng  ere  eepeble  et 

WWV/lfip  VfVW^WipnViW  IfWOTWrl  rVfrvPvrW 

t  Deteet  eny  oyofom  tenure  or  gegregetlen  which  weulg 
egvereely  etteet  the  eyetem'e  eblllty  te  eetlety  he  mieelen 
ebfeegvee. 

All  BIT  Implemeniellene  et  thie  requirement  ehell  be  eentelneg  within  the 
eyeiem  or  eubeyeiem  hergwere  eng  wHI  net  gegrede  mieelen  pertermenee  el 
enybme 

S.t.4.X.4.1.1  Ne-Oe  Gengitlen  Oetectlen  •  The  eyetem  en-llne  BIT 
pertermenee  menherlng  teeturee  ehell  geleet  el  leeet  pereent  et 

ell  ne-ge  eengitlen  eeeurreneee  ever  the  mieelen  time.  (A»  epplleg  et  the 
weepen  eyeiem  level  or  ee  epplleg  IndepengenUy  et  the  eubeyeiem  level.) 


ioniinutd  on  iH«  following  pagt... 
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9.2.4. X.4,1,i  M»0  Alarm*  •  Tha  numbar  of  talaa  alarm*  ahall  nat  ****** 

_ paraant  of  all  inPlaata*  no-go  oondition  oeeurraneaa  or 

allomataly  no  moro  than  IntIleaM  no-go  oon*ltl*n  oeourroneaa  In 

any  htogratad  i44tow  parlo*  ot  ayalam  oporaPng  Pm*. 

S.Z4,X,4, 1.9  Partonnanoo  IPonltor  and  9alf-T**t  Data  -  Poitormane*  moatfor 
and  aalMaat  data  atall  bo  tranamitiad  In  a  mannor  aueh  dial  tha  iranamltlad 
data  ahall  follow  tho  aotual  condition  ot  tha  ayalam,  that  la,  a  malfuhatlon 
whioh  eorracta  limit  ahaU  ohanga  tha  tatdt  data  lino  aoeordingly, 

9.1.4. X.4,i  Ott-Una  BIT  -  Tha  iyatam  J^IT  proylalon  ahall  tumlph 

tha  maana  tor  an  oparator  to  Initlat*  BIT  taata  tor  potpoaoa  ot  datarmlning 
and  diaplaying  tha  tunatlonal  atatua  *t  tha  ayatama/aahayatom  Inaluding  a 
fault  dataotlon  and  laoladon  oapablllty.  Tha  Intandad  wm  ot  tha  4INIna  BIT 
taata  la  two-toldi  aa  a  ayatam  raadinaaa  taat  to  pdrmlt  oparatihg  eraw  to 
aooumulata  atatua  and  fault  kitormatlon  on  an  opportuntly  baala  prior  la  and 
during  oparaMonai  and  than  vaitty  a  Muff  Indloatad  during  oporatlon  and  to 
laolal*  tha  fault  at  tha  Orgatdmdonal  lavol  ot  mahtananoa, 

9.9.4. X.4J.1  No-Bo  Oondldon  Dataotlon  -  Tha  ayalam  otNIna  BIT  loaturoa 

ahall  dataot  at  laaaa . paroant  of  all  no-go  oenditlon  ooourranoaa, 

(Aa  applied  at  tha  weapon  ayatam  laual  or  aa  applied  Indapandandy  at  Bia 
aubayatam  lavoL) 

9,t.4,X,4,i.i  Palm  Alarm*  •  The  numbar  ot  talm  alarm*  ahall  not  o*omd 
■■  paroant  ot  all  Indloatad  naiN>  oenditlon  ooourranoaa  or  ahamataly 
no  mar*  than  ....  indloatad  no-go  oenditlon  oeourranooa  In  any 
Intagratad  i4-hcur  period  at  ayatam  operating  bma. 

9J.4.x.4.t.9  Ott-Un*  BIT  Pault  Dataetlen  -  The  otNIna  BIT  fault  dataotlon 
oapablllty  ahall  be  daaignad  M  monitor,  dataot,  and  ovaluata  fault*  on  all 
ayatam  or  aubayatam  tunotlona  amllabi*  at  tha  ayatam  or  aubayatam 
Intartaoa,  Whan  a  fault  or  ayatam  degradation  la  dataeidd,  tha  oft-lln*  BIT 
praolalan  may  dotarmlna  tha  amount  at  degradation  and  autematloally 
branch  Into  tho  appraprlata  dtagneado  Muff  laelatlen  reudna. 

9.1.4. X.4.i.4  Ott-Una  BIT  Pault  laolatlon  •  Tha  otNIna  BIT  fault  laelatlen 
routinaa  ahall  b*  provided  at  each  fault  dataotlon  point  and  ahall  ba 
autematloally  ontorad  whan  a  no-go  la  dataotad.  Tha  ett-lln*  BIT  ahall 

provid*  fault  legation  (e  otto  Una  Poplaemblo  Unit _ paroant  of  tho 

Uma,  fault  laelatlen  to _ _  or  tower  Lino  Poplaooabl*  Unit* _ 

paroant  of  tha  time.  In  no  earn  ahall  tha  ambiguity  group  bo  groatar  than 
_ UtU(a). 
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on  tho  following  pogo.. 


a,t.4.x,t8  OthLlM  »(r  PmiH  too/affon  Vim  -  Tha  otNim  BIT  fnH  Imlatlon 
Him  9h§ll  da  oomltlmt  with  ma  nquliwmnt§  cf  fda  Organlutlon§l  /ava/ 
Maan  TTma  To  Mapadr  fMrnv  nni^mmnta. 

S.Z4.X,4J  BIT  Ban  Tmt  <•  BIT  mit  Hat  firovlalona  ahall  ba  ineorporataB  Into 
tha  ayatam,  Tha  tima  tor  tha  BIT  aalf  tool  ahall  bo  laaa  than 

fand/or  tha  duhievela  of  tha  BIT  oaltla^  ahall  ba _ J.  ThaBIT 

tallura  rata  ahall  ba  laaa  than _ paroant  ot  tha  pilma  ayatam  BIT  tallura 

Indloatlon  rata. 

9J,4.X.4J  miBalabiaalalom^ThaolroultaanddavloaawhlohpiovMaBIT 
and  fault  laolatlon  tunoHona  ahall  ba  daaignatad  In  aueh  a  mannar  that 
tallura  of  thaaa  alreulta  and/or  davloaa  will  not  eauaa  a  orltlaal  tallura  or 
unaataaodon  ot  tha  ayatam, 

9.1.4. x,4.i  Bklll  Lovala  •  A  paraannal  akill  laual  ot _ _  la  raquirad  to 

parmit  tha  aooompllahmant  at  all  aaUom  aaaaolatad  with  tha  fault  laalaBan 
and  ramoual/raplaoamant  ot  LttUa  at  Ida  Oparatlanal/Organlaatlonal  laval. 
BiTpraalalona  and,  whora  radulrad,  Organludoml  la\ml  taat  aqulpmant  and 
maintananoa  prooaduraa  will  ba  uaad  to  provda  fault  laolatlon  within  Bia 
bnrm  apaomoallon. 

9.t4.X.i  TaatB<iulpmantbitarlaea*BlBnalaohaHbalmludadatHiamodida 
intartaaa  whioh  maabnlaaa  tha  almdarny  atbuUHn  taatmg  by  tha  odidpmant 
and  axiamal  taatbig  by  manual  taat  aqikpmant  and/ar  on  ATM  ayatama.  Tha 
ayatam  ahall  ba  daaignad  tar  oampatiblllty  tar  taat  with  tha  aalaotod  or 

targatad  AfB  (or . . (Inoart  taat  aquipmant  namo/dooignatar)}, 

Maaimum  urn  ahall  ba  mada  ot  oporatlanal  pim  to  prouldo  toot  oontrol  and 
aooaaa  fo  aattaiy  tfia  fault  doiaotlon/tault  laolatlon  raquiramonta  otaxiamal 
taat 

9.1.4. K$  Taat  Tolaranaaa»ApproprlataMaranooa  mid  ^gnallhniwahallba 
aatabllahad  In  diagnoatio  rautinaa  at  aaoh  loual  whioh  tha 
ayatam/aqulpmanta  ara  aublaot  to  taadng  auoh  that  lalaa  alarma  and  Maiaaf 
Okay  rataa  ara  nMndaad. 

9.g.4,x.7  TaohnhalbilarmatlonAoeamVma^AyaragaltmaraquIradtortha 
maintananoa  to^nMan  fa  aooaaa  maintamnoa  taohnioal  Information  ahall 
bo  laaa  than  mkiutaa  at  tha  Orgamaathnal  favafl 


Configuration  Itom  Davtiopmant  8paolflcatlon 

A  modal  taatablllty  spaclfloatlon  auitabla  for  Inclusion  In  tha  Cl 
davalopmant  spaclfloatlon  Is  provida  as  follows. 
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MODEL  CONROURATION  ITEM  DEVELOPMENT  SPECIRCATION 


S^.4.X  Dla§noBUc»/r*»t»bUHy  •  Th*  aubty$fmXtm  (ln»9ri  imm)  •hall  ba 

^••Itnml  lor  lattabUlly  and  aatialrualad  to  parmll  Un  atatua  of  tha  aubayatam/ltam 
and  tha  unamUtuaua  laaathn  at  laulla  to  ha  aonildantly  datarmlnad  tfnd  raportad  In 
a  dmalf  faaNan. 

9 J.4.X.  1  Partitioning  (funethnal  Modulartty)  •  gabayatamantama  will  bo  partitlonod 
Into  9hop  Poplaaoablo  Unlla  (9PU)  baaad  on  tha  function,  minimum  or  optimum 
numbar  of  miaraonnaadona,  tha  ability  to  fault  laalata  dia  cotraot  unit  and  tha  abUhy 
of  paraonnal  with  tha  aid  of  aupport  apulpmant,  training,  and  taohnlaal  monuala  to 
fault  laolata  to  tho  oanoot  unit. 

Toathointa  and  Oontaata  •  Taatpointa  and  eontaota  ahaH  bo  aonuanlontly 
loaatad  and  haua  aafa  aaoaaa  to  aignal  nodaa  on  tho  unit  under  taat,  and  ahall  ba 
proutdod  for  tfi«  maaaura  or  /n/Mtfon  of  algnlflaant  paramatora  for  tha  purpoaa  of 
evaluating  or  troubtoahoodng  tfM  alroult  meohanlama.  The  number  and  aholoo  of 
aaoaaalbla  nodaa  ahaX  ba  auHMent  to  abt^n  the  egulpmant  fault  dalaollon/loalallon 
roquiremanta  llatod  harabi, 

iJi.4.X.$  Olagnoatlaeapablllty -Per  each  level  of  maintananaot  all  dlavtaada 
raaouroaa  ahall  ba  Integrated  to  provida  a  aonalatant  and  aamplate  diagnoatle 
capability.  A  complato  dlagnoado  aapabUlty  muet  Identify  tho  diagnoatle  raoauraaa 
that  will  ba  uaod  to  have  full  PD/PI  covaraga  Th*  dam—  af  diagnoatle  automation 
ehell  bo  aonalatant  with  tha  propaaed  paraonnal  eklU  levala  and  malntananoa  rapab 
Itama. 

9J.4.X.4  §ullt-k 
•ubayatam/llem 
r^r^t^rlr^mt^tnta. 

5.1.4, X.4, 1  OmLIno  BIT  Parformanea  Monitoring  •  Tho  omllno  BIT  parformanca 
manitoring  faaturaa  ahall  ba  aparativa  and  ahall  provida  valid  parformanea 
Indlaatlona  prior  to  and  during  operation.  Tha  parformanea  monitoring  operation 
•hall  ba  automatic  and  eontinuoua  ahall  bo  automatio  and  aontinuoua  and  will 
monitor  aalhoontalnod  aignal  generating  ahauhry.  All  BIT  Implementatlana  of  thla 
roquiramant  ahall  ba  aontalnod  within  to*  ayatem  or  aubayatam  hardware  and  wfH 

flvi  OVpraW  mlWIVfl  Vf  ^ef  ■fTWi 

$.i.4.X.4. 1. 1  Mo^o  Condition  Ootaatlon  •  Tha  ayatem  omllno  BIT  parformanea 
monitoring  faaturoa  ohall  dotoct  at  laaat  poraont  of  all  no-go  oondlUon 

OOVUffVfWMi  (AV  IrWipOTVVwrni^  «f  Olv  VIHN/VIWn  IVWfy 

9JI.4,X.4.1.t  Palao  Alatma  -  The  number  of  falea  alarma  ahaH  not  aaaeod 
poraont  of  all  Indleatod  no-go  candHIon  oaaurranaae  or  altamataly  no  more  than 
__  Indicated  no-go  condition  oaourraneoa  In  any  Integrated  id-hour  period  of 

•JFSIMII  OpWPfip  IMfMb 

1.1.4. X.4,1.S  Performanao  Monitor  and  9alf-Taet  Data  •  Parformanao  monitor  and 
aalt-teat  data  ahall  bo  tranamittad  In  a  manner  eueh  that  the  tranamittad  data  flow 
ahall  ba  trarmmlttad  bi  a  manttar  auch  that  lha  irancmitfad  data  ahall  fallow  Pta  actual 
aamUtlan  of  tha  ayatem,  that  la,  a  malfunatlan  whiah  aorraata  Itaalt  ahall  ahange  the 
fauh  data  Una  aacordbii^. 


dontinufd  on  ih«  following  pogt... 


I  fMt  •  BuHt-m  Teat  (BIT)  provlalona  ahall  bo  added  to  tho 
to  eadafy  ayatam-level  performanae  monitoring  and  oft-llna  BIT 


1-21 


SJ14.X.4J  OtMnt  iff**  TT»# _ •ub9y«lm  BIT pro\rt$lon  •hatf  HimlBh 

thB  m9»n§  for  on  oporotor  to  inttloto  BIT  looto  of  Iho  oyotom  lovol  tor 
purpooo  of  Ooformlnlnp  ondl  dioploying  tho  tunetlonol  ototuo  of  tho 
oyotommupoyotomo  Inoludfng  o  touH  dotooUan  and  itMfton  eapabUlty.  Tho 
Infondod  uoo  of  tho  ofNIno  BtT  loot  to  two^foldt  oo  o  oyotom  roodinooo  toot 
topomit  oporoting  orow  to  oooumuloto  ototuo  and  fault  Information  on 
opportunity  boolo  prior  to  and  during  oporotlonof  and  to  vorlty  a  fault 
Indloolod  during  oporotlon  and  to  loololo  tho  touh  at  Iho  Orgonloahonol  lovol 
otmohitononoo. 

9.1.4. X.4JI.1  No^  Oondltfon  Ootootlon  •  Tho  oyotom  othlino  BIT  footuroo 
oholl  dotoot  at  moot  aoroont  of  all  nono  oondihon  ooourronooo.  (Ao 
oppIlodlndopondonllyotthoouboy^omlovoQ 

$,t,4,X.4.t.i  Moo  Alormo  •  Tho  numbor  of  foloo  olormo  oholl  not  oxeood 
poreont  of  all  Indlootod  no^  oonditlon  ooourronooo  or  oliomotoly 
no  moro  than  Indlootod  no-go  oonditlon  ooourronooo  In  any 
miogrolodi44murporlodofoyotomoporoilngilHio. 

s.a.4,x.4.is  Otf-LIno  BIT  Boull  Potootlon  •  Tho  ott-lino  BIT  fault  dolootlon 
eopoblllty  oholl  bo  dooignod  to  monitor,  dotoot,  and  ovoluoio  foulto  on  all 
oyotom  or  ouboyolom  funottono  ovoiloblo  at  tho  oyotom  pr  ouboyotom 
Intortooo.  Whan  a  fault  or  oyotom  funodon  dogrodotlon  la  dotootod,  tho  ofP 
lino  BIT  provlolona  oholl  dotormino  tho  amount  of  dogrodotlon  and 
outomodoollyhronoh  Into  Iho  opproprioto  diognootio  fault  loolotlon  roudno. 

$,a.4,X.4.a,4  OfhUno  bit  Poult  loolauon  •  Tho  ofNIno  BIT  fault  loolotlon 
rouUnoo  oholl  bo  providod  at  oooh  fault  dotootlon  doololon  point  and  oholl  bo 
outomatioolly  ontarod  whan  a  no-go  la  dotootod,  Tho  off-IIno  BIT  oholl 
provfdo  fouh  loolotlon  to  ono  Bhop  ftoplooooblo  Unit  Hot  tho  hmo, 
fauP  laolatien  to _ or  fomor  Bhop  ftoplooooblo  Unlto  ..  Hot  tho  Brno. 

9.a.4.X.4,a.t  OthLIno  BIT  Poult  loolotlon  TImo  •  Tho  oft-IIno  BIT  fault 
loolotlon  dmo  oholl  bo  oonolotont  with  tho  roquiromonto  of  bloon  TImo  To 
ftopolr  (Mrwi  roquiromonto. 

9.2.4, X4J  BIT Bolf  Toot- BIT oolt toot provMono oholl bo Inoorporotod Into 
tho  aubovotom/ltom.  Tho  timo  tor  tho  BIT  ood  toot  oholl  bo  looo  than 

_ (ondfor  tho  duty  oyolo  of  tho  BIT  o^t  toot  oholl  bo _ ),  Tho  BIT 

tolluro  rota  oholl  bo  looo  than  %  of  tho  primo  oyotom  BIT  tolluro 
Indlootlon  mio. 

9J.4,X.4.4  Ml  Bom  ProWolono  •  Tho  oiroulto  and  dovlooo  which  provfdo  BIT 
and  fault  loolotlon  tunotlono  oholl  bo  dooignod  In  oueh  o  monnor  that  tolluro 
of  thooo  oiroulto  ond/or  dovlooo  will  not  eouoo  o  orllloal  tolluro  or  unooto 
aoUon  of  tho  ouboyotom/ltom. 
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on  the  Tollowlng  page... 


9.2.4. X.9  Skill  L0vla  -  A  p*monn»l  tklll  Itvl  of _ /•  nquind  to  pormlt 

tho  Moeompllohmont  of  til  aollono  ooooelotod  with  tho  foult  loolotlon  »nd 
romovki/roploeomont  of  BMo  ol  tho  Momodlato  maintonaneo  laval.  BIT 
provlalona,  taat  aquipmani  and  maintananaa  proeaduraa  will  ba  uaad  le 
provida  fault  laolallon  within  tha  UTTS  apaelhoatlon, 

3.2.4. X.7  Taat  Bqulpmant  Intarfaea  •  SIgnala  ahall  ba  Includad  at  tha  modula 
Intarfaeaa  which  maximlaa  tha  almllarlty  of  buIMn  taating  by  tha  aquipmant 
and  off-board  taating  by  manual  taat  aquipmant  and/or  on  ATS  ayatama. 
Tha  ayatam  ahall  ba  daaignad  for  compatibility  for  taat  with  target  off-llna 
automatic  taat  aquipmant  Maximum  uaa  ahall  ba  mada  of  oparaticnal  plna 
to  provida  taat  control  and  aeeaaa  to  aatlafy  tha  fault  dataetlon/fault 
laolatlon  raquiramanta  of  ofhboard  taat 

1.2.4. X.a  LRU  Fault  Dataetlon/laolatlon  Raquiramanta  -  Tha  following 
raquiramanta  apply  to  fault  dataetlon/laolatlon  capability  at  tha  Intarmadlata 
laval  of  maintananea  uaing  automatic  taat  raaourcaa  (ATB7TP3  and  Btf}. 

•  Fault  laolatlon  ahall  ba _ pareant  of  all  organlxatlonal 

dalaotad  falluraa. 

•  Avaraga  (or  maximum)  taat  lima  for  QO/NO-QO  and-to-and 

taata  ahall  ba  laaa  than _ (mlnutaa/houra). 

-  Maximum  rata  of  talaa  NO-QO  Indleatlona  raoulting  In  Cannot 

Dupileataa  and  Rataat  Okaya  ahall  ba _ pareant  of  all 

Organlxatlonal  laval  dataetad  lailuraa. 

•  Fault  laolatlon  capability  ahall  provida  fault  laolatlon  to  ona 

BRU _ pareant  of  tha  tima,  fault  laolatlon  to _ or  lawar 

BRUa  oarcant  of  tha  tIma.  In  no  caaa  ahall  tha  ambiguity 
group  alxa  ba  graatar  than _ 8RU(a). 

•  Avaraga  (maximum)  diagnoatle  fault  laolatlon  tima  ahall  ba 

laaa  than _ (mlnutaa/houra). 


a.2.4.X.9  BRU  Fault  Dataetlon/laolatlon  Raquiramanta  -  Tha  following 
raqulrrnmanta  apply  to  fault  dataetlon/laolatlon  capability  at  tha  Dapot  lavol 
of  maintananea  uaing  autemahe  taat  raaouroaa  (ATB/TPB  and  BIT). 

-  Fault  laolatlon  ahall  ba _ pareant  of  all  dataetad  falluraa. 

•  Avaraga  (or  maximum)  taat  tima  for  QO/NO-QO  and-te-and 
(9«li  ahall  ba  laaa  than _ (mlnutaa/houra), 

-  Maximum  rata  of  falaa  NO-QO  Indleatlena  raaulting  In  Rataat 

Okaya  ahall  ba _ pareant  of  all  dataetad  falluraa. 

-  Fault  laolatlon  capability  ahall  provida  fault  laolatlon  to  ona 

eemoonant  pareant  of  tha  tima,  fault  laolatlon  _ 

or  tawar  eempenanta _ pareant  of  tha  tima,  in  no  eaaa 

ahall  tha  ambiguity  group  alxa  ba  graatar  than _ 

eemponanta, 

-  A  varaga  (maximum)  diagnoatle  fault  laolatlon  taat  tima  ahall 

ba  laaa  than _ (mlnutaa/houra). 


RESPONDING  TO  AN  RFP, SOW, SPECIFICATION 


REQUIREMEt^  #1.2 


CHECKLIST 

E2f  Dom  the  specification  cover  100X  of  the  FD/FI 
requirements  for  each  level  of  maintenance? 


E3f  Has  the  concept  of  "dlognostic  growth"  been 
invoked  in  the  diagnostic  specifications? 


□f  Hove  oil  the  diagnostic  element  requirements  been 
quantitatively  specified?  Both  fault  detection 
and  fault  Isolation? 

Has  inherent  testabiliiy  been  addressed  adequately? 
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DIAGNOSTIC  CAPABILITY  PROGRAM  PUNNING 


REQUIREMENT  #1.3 


AOQ.  PHASE 


WEAPON 

SYSTEM 

ACTIVITIES 


OPER.  CONCEPT  DEM/ 

REOMTS.  EXPLOR.  VAL 


PROD/ 

DEPL. 


DIAGNOSTIC 

ACTIVnriES 


PREPARE/UPDATE  DIAGNOSTIC  CAPABILfTY  PROGRAM  PUNS 


DIAGNOSTIC  ACTIVITY 

Program  planning  It  rtquirod  to  onturt  that  tha  davalopmant  and  support  of  tha 
diagnostic  capability  Is  proparty  managed  throughout  tha  acquisition  of  a  weapon  system. 
This  planning  must  address  how  this  development  will  be  conducted  to  achieve  this  goal. 

Program  planning  for  the  development  of  the  diagnostic  capability  Is  required 
throughout  the  acquisition  of  the  weapon  system.  It  begins  soon  after  the  award  of  the 
first  developmental  contract  and  Is  expanded  and  updated  as  the  development  proceeds. 

The  program  planning  can  take  the  form  of  a  single  Diagnostic  Capability 
Program  Plan  or  can  be  Incorporated  In  a  series  of  program  plans  which  are  described  In 
■  number  of  programmatlc>type  military  standards.  The  requirements  of  these  planning 
documents  will  be  defined  In  the  contract's  Statement  of  Work.  To  avoid  unnecessary 
duplication  of  programs  plans,  the  Inclusion  of  this  planning  Information  In  existing 
documents  Is  preferred. 

QUIPANCg 


Each  of  the  management-type  plans  Is  required  during  specific  phases  of  the 
weapon  system  acquisition.  The  following  (Table  3)  Is  a  listing  of  the  plans  and  phases 
where  these  plans  are  generally  required.  The  designer's  Input  to  the  System 
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DIAGNOSTIC  CAPABILfTY  PROGRAM  PLANNING 


REQUIREMENr  #1.3 


Englnatrlng  Manag«m«nt  Plan  la  particularly  Important  baoauaa  of  tha  naad  to 
Incorporata  diagnoatio  dasign  aa  an  Intagral  part  of  tha  system  engineering  process. 


TABLE  3  -  APPLICATION  MATRIX 


PLANTTTLE 


SYSTEM  CNOINCERINO 
(81 

loowfw  . 

ANALYSIS  PUN  (I.8AP) 


CC  I  DEMAAL  I  PSD  PROD 


ML-ffD-4H 


yL-fn-ISM-l 


lESTABLmr 
PROGRAM  PUN 


RELIABLITY 
PROGRAM  PUN 


ML-ffD-Tia 


MAINTAINAILITY 
PROGRAM  PUN 


IKTSORATEO 
SUPPORT  PUN  (ISP) 


SYSTEM 
SAFETY  PUN 


HUMAN  ENGINEERING 
PROGRAM  PUN 


TEST  AND  EVALUATION 
MASTER  PUN  (TEMP) 


DIAGNOSTIC  CAPABILfTY  PROGRAM  PLANNING  REQUIREMEhfT  #1.3 
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PREPARATION  OF  SCPi/DCPi 


REQUIREMENT  #1.4 


M 


WEAPON 
SYSTEM 
ACQ.  PHASE 


OPER.  CONCEPT 

REQMTS.  EXPLOR. 


WEAPON 

SYSTEM 

ACTMTIES 


DIAGNOSTIC 

AcnvmES 


SCP 


DEM/ 

VAL 


FSD 


PROD/ 

DEPL 


TTTJ 


APPROVAL  TO 
PROCEED 


LOGISTIC 

REVIEW 


S" 

DCP 


A '  “A  A 
ui5S&e 


DIAGNO8TI0  ACTIVITY 

Prior  to  Mllottonot  I  through  V  (DoO  Initruotlon  6000.2),  tho  proparitlon  of  ■ 
paptr  la  raqulrod  to  aummarizt  tho  ro aulta  of  tho  aoquialtlon  and  doploymont  of  a  major 
woapon  ayatom.  Prior  to  Oom/Val,  a  Syatom  Conoopt  Papor  (SCP)  la  roquIrKi.  Prior  to 
FSD,  proparatlon  of  a  Doolalon  Coordinating  Papor  (DCP)  la  roquirod.  An  updato  of  tho 
DCP  la  roquirod  prior  to  Mllootonoo  III,  IV,  and  V.  Tho  SCP  and  tho  DCPa  for  Mlloatonoa 
II  and  III  aro  roquirod  to  aoouro  approval  to  prooood  to  tho  noxt  aoquioitlon  phaao. 
Mlloatono  IV  la  a  loglatio  roadinoaa  and  aupport  rovlow,  which  la  oonduotod  ono  or  two 
yoara  aftor  doploymont  to  aoauro  that  oporatlonal  roadinoaa  and  aupport  objootivoa  aro 
aohlovod.  Mlloatono  V  la  a  major  upgrade  or  ayatom  roplaoomont  doolalon,  which  alao 
roquiroa  an  updating  of  tho  DCP.  DIagnoatIo  laauoo  ahould  bo  addroaaod  In  thoao 
dooumonta. 

PRQfiBBUBi 

DoD  Inatruotlon  5000.2  dollnoatoo  tho  nood  and  tho  format  for  both  an  SCP  and 
a  DCP.  It  la  llkoly  that  thla  dooumontatlon  will  addroao  diagnoatio  laauoa.  Although  Ihia 
typo  of  dooumontatlon  la  roquirod  only  for  major  woapon  ayatoma,  almllar  dooumontatlon 
may  bo  roquirod  by  tho  Individual  aorvlooa  at  algnHIeant  mlloatonoa. 


PREPARATION  OF  SCPi 


REQUIREMENT  #1.4 


aUlBAUfiS 

TlH»t«  dooumtvnoc)  Aivvaya  prtptrAd  by  th#  OovArnmam  Program 
Managar.  Tha  daalgnw  a  awa*a  that  hia  Inputa  to  tha  praparatlon  of  thaaa 
dooumtma  may  hava  an  Inttaot  on  tha  futura  of  hia  daaign. 
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REQUiREMENTS 


REQUIREMENT  #2 


B8TASU8HINQ  AND  ALLOCATINQ  OIAQN08T1C  RKQUIRBMBNT8 


ftYiBYMBtf 

Qood  diagnostics  and  tastablllty  art  basad  on  tha  ability 
to  proparly  astabllsh  dlagnostlo  raquiramants,  whioh  art 
In  turn  basad  on  waapon  systam  mission, sustainability, 
oparatlonal,  and  support  raquiramants  and  tha  ability  to 
allooata  thasa  raquiramants  at  systam,  subsystam,  and 
unit  iavals.  Laok  of  appropriata  attantlon  to  this  prooass 
rasults  In  diagnostic  dasigns  with  quastlonabla  basis 
and  justification.  Unfortunataly,  thia  prooass  has  not 
baan  transformad  from  an  art  to  a  rigorous  mathodology. 
An  Intagratad  satiaa  of  provan  tools  doas  not  axlst  and 
thus  tha  quality  of  tha  analysis  dapands  on  tha  axpartisa 
of  tha  parsons  parforming  thia  analysis.  Tha  systam  Is 
furthar  oompiloatad  by  tha  advanoad  waapon  systam 
arohitaotura  which  Is  now  baing  appllad.  This 
arohitaotura  invoivas  oompiax  radundanoy, 
raoonfigurabla  alamants,  and  oonfigurations  whioh 
raquira  graoaful  dagradation.  A  propar  analysis  Is  an 
Intagrai  part  of  logistio  support,  raliablllty,  and 
maintainability  onalysas  and  Is  basad  on  tha  waapon 
systam's  mission  soanario  and  parformanoa 
raquiramants.  Tha  analysas  ara  an  Itarativa  prooass, 
whioh  axtand  ovar  tha  acquisition  phasas  and  oftan  into 
daploymant  of  tha  waapon  systam.  Implamantatlon  of 
thasa  analysas  Is  normally  tha  rasponaiblllty  of  tha 
Contractor  Program  Manager,  with  tha  raauKs  raviawad 
by  tha  Qovammant  Program  Manager. 


TESTABILITY/ 


DIAGNOSTICS 


Wqmt 

2.1  Tranalata  mlaslon  and  parformanoa  raquiramants  Into  diagnostic 
raquiramanta. 

2.2  Allooata  dlagnoatle  raquiramanta  to  ayatam,  aubaystam  and  unit  alamants. 

2.3  Optimixa  tha  mix  of  dlagnostlo  alamanta. 

2.4  Aaaaas  tha  risk  of  each  diagnostic  altarnativa. 
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TRANSLATING  MISSION  REQUIREMENTS 


REQUIREMENT  #2.1 


WEAPON 

OPER. 

CONCEPT 

DEM/ 

FSD 

PROD/ 

SYSTEM 
ACQ.  PHASE 

REQMTS. 

EXPLOR. 

VAL 

depl: 

WEAPON 


AcnvmEs 


DIAGNOSTIC 

AcnvmEs 


CONTRACT 

AWARD 


BiAQNflflmflAgnyuY 

Dlagnottlo  rtquirtmtntt  art  kjtntifitcl  in  tht  Conotpt  Exploration  Phaia  from  an 
analysis  of  ths  prims  systsm  mission  and  opsrational  rsquirsmsnts. 

PRQfilBUBi 


Ths  Qsnsratlon  of  wsapon  systsm  opsrstlonal  rsquirsmsnts  Is  usually 
psdormsd  by  ths  govsmmsnt  from  mission  studlst  and  analysts  batsd  on  ths  Statsmsnt 
of  Nssd  for  a  wsapon  systsm.  Ths  translation  of  thoss  rsquirsmsnts  and  wsapon  systsm 
psrformanos  oharaetsristlot  Into  dlagnostlo  rsquirsmsnts  Is  psrformsd  during  Conospt 
Exploration.  Ths  tasks  Invoivsd  In  translating  thsss  rsquirsmsnts  may  bs  psrformsd  by 
ths  oontraotnrs  or  ths  govsmmsnt  dspsnding  upon  ths  acquisition  proosss  ssisotsd  during 
Conospt  Exploration.  For  "ln>houss*  programs,  this  task  It  psrformsd  by  govsmmsnt 
snginssrs.  Frsqusntly,  howsvsr,  ths  translation  of  mission  and  psrformanos 
oharaotsiistlos  Into  diagnostic  rsquirsmsnts.  ths  ssisotlon  and  Intsgratlon  of  ths  diagnostic 
sismsnts  to  mast  thsss  rsquirsmsnts,  ths  allocation  of  thsss  rsquirsmsnts  to  subsystem 
and  unit  Isvsl,  and  ths  ssssssmsnt  of  risk  Is  psrfonnsd  by  ths  wsapon  systsm  oontraotors 
In  a  oompstitivs  snvironmsnt. 

Ths  propsr  Impismsntatlon  of  this  task  Is  that  It  bs  psrformsd  In  conjunction  with 
ths  systsm  snginssring  and  logistic  support  analysis  proosss  and  Include  synthesis  and 
analysis  of  ths  various  mixes  of  rssouross  which  make  up  a  total  diagnostic  subsystem. 
Ths  diagnostic  rsquirsmsnts  analysis  proosss  involves  ths  development  of  a  strategy  for  a 
oomprshsnslvs  diagnostic  capability  Including  a  mix  of  rssouross  to  bs  defined  for 
providing  FD/FI  capability  at  each  Isvsl  which  ths  system  Is  subject  to  maintenance. 
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TRANSLATING  MISSION  REQUIREMENTS  REQUIREMENT 


Dtftoriptions  of  tools  that  aro  availabia  to  assist  In  tha  antirs  procass  of  astabllshlng  and 
allocating  diagnostic  raquiramants  ara  oontsinad  in  Appendix  C. 

In  order  to  translate  mission  and  operational  raquiramants  to  diagnostic 
capability.  It  is  Important  to  postulate  a  "diagnostic  subsystem."  Characttrlstlcs  defining 
tha  capability  of  tha  "diagnostic  subsystem"  represents  the  results  of  the  translation.  In 
othf  r  words,  one  must  change  mission  requirements  into  diagnostic  capability  definitions 
In  order  to  successfully  oomplete  this  task. 

The  diagnostic  elements  constituting  the  diagnostic  subsystem  Include 
embedded  support,  support  equipment  at  all  levels  of  maintenance,  technical  data  In  all  Its 
forms,  and  personnel  numbers  and  required  skill  levels. 

In  order  to  be  responsive  to  weapon  system  mission  and  performance 
requirements.  It  Is  essential  that  the  translations  start  by  reviewing  all  the  requirements 
documentation  and  studies.  The  key  document  Is  the  Statement  of  Need  which  contains 
the  weapon  system  mission  and  operational  requirements.  Also  Important  Is  the  prime 
system  architecture  driven  by  technology  Infusion  Into  the  prime  system.  This  Is  an 
essential  element  In  the  translation  since  many  prime  system  architectural  concepts 
contain  an  Inherent  diagnostic  capability  which  must  be  IdentHled  and  addressed  early  In 
the  analysis  process. 

There  are  two  key  factors  which  will  Influence  the  translation  of  weapon  system 
mission  and  operational  requirements  Into  diagnostic  requirements.  They  are: 

0  Spedfio  requirements  as  spelled  out  in  tho  Statement  of  Need 

0  Avallabis  technology. 

Analysis  of  these  specific  requirements  will  translate  to  both  requirements  for 
the  diagnostic  capability  as  well  as  constraints  on  the  diagnostic  subsystem  dictated  by 
the  operational  parameters.  The  technology  will  Impact  the  Inherent  diagnostic  capability 
of  the  prime  system  architecture  as  well  as  Impact  the  assessment  of  risk  of  the  final 
diagnostic  subsystem  implementation. 

Based  upon  the  above  analyses,  translation  of  mission  and  operational 
requirements  to  a  diagnostic  capability  will  result  In  a  preliminary  set  of  diagnostic 
requirements  for  the  entire  diagnostic  subsystem.  The  optimum  mix  of  diagnostic 
elements  which  constitute  the  diagnostic  capability  will  follow  the  requirements  alloratlon 
to  the  weapon  system,  subsystem  and  unit  levels. 

During  the  Demonstratlon/Valldatlon  Phase  and  Full*Soale  Development  Phase 
tho  detailed  trade  studies  will  formally  optimize  the  diagnostic  element  mix  and  provide 
Implementation  apeclflcatlona  for  the  diagnostic  subsystem  to  be  produced.  This  process 
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TRANSLATING  MISSION  REQUIREMENTS 


REQUIREMENT  ifZI 


Is  obviously  Hsratlvs  but  most  doptndtnt  upon  a  thorough  Job  of  mission  and  parformance 
raqulramants  analysis  and  Initial  translation  Into  diagnostic  raquiramants. 


For  axampla,  tha  OanWal  Phasa  may  rasult  In  a  Systam  Spaolfioation  only,  with 
tha  allocation  of  tha  systam  raqulramants  to  ba  parformad  and  radafinad  In  tha  PSD 
Phasa.  For  soma  lass-than-major  aystams,  DamA/al  Phasa  may  ba  bypassed  altogether. 
In  this  ossa,  both  tha  systam-laval  spaoifloatlons  may  ba  developed  during  PSD  Phasa. 


liLl  UMW 1 1  lf[  I  MilTTaviHiirimiiiiMii'iii'iia 

TTTtrrnw^ 


CTffiK!  iTM  TiPrf m  ^ifmsxm  f;.i 


qVIPANGB 

Tools  are  available  to  assist  In  establishing  weapon  systam  diagnostic 
raqulramants.  Appendix  C  has  a  oompllatlon  of  these  tools.  Mainly,  they  address  tha 
logistic  support  analysis  process  along  with  readiness  and  oost  models.  However,  there  Is 
no  formal  OoO  modal  for  translating  mission  and  operational  raqulramants  Into  a 
diagnostic  capability.  Using  systam  engineering  approaohas  defined  In  MIL>8TD>499, 
along  with  available  models,  tha  contractor  can,  Indaad,  davalop  an  Initial  sat  of  diagnostic 
subsystem  raqulramants  which  are  traoaablo  to  weapon  system  raqulramants,  weapon 
systam  priorities,  and  available  technology. 

Success  In  translating  mission  and  operational  raqulramants  Into  diagnostic 
raquiramants  is  embodied  In  tha  ability  to  davalop  higher  order  measures  for  defining 
weapon  systam  charaotartstles  that  relate  to  fault  detection  and  fault  Isolation  parameters. 

Typical  weapon  systam  charaotartstles  which  must  ba  evaluated  Include  tha  following; 


Probability  of  Mission  Success 

Availability 

Utilization  Rata 

Population 

Turnaround  Tima 

Threat 

Mobility 

Safety 

Alert 


Deployment 

Basing 

Weight 

Repair  Concept 

Personnel 

Training 

Cost 

Etc. 


Typical  weapon  system  priorities  are  as  follow; 

War  fighting  capability 

Survivability 

Mobility 

Manpower 

Life  Cycle  Cost. 
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TRANSLATING  MISSION  REQUIREMENTS  REQUIREMENT  #2.1 


During  tht  Concept  Exploration  Phaaa,  mlailon-orlantad  maasuras  ara 
ovarriding  for  diagnoatio  raquiramanta  ganaratlon.  Raaouroa  orltarla  (manpowar.  cost, 
facllltlai,  ate.)  baeoma  aignifloant  during  aynthaals  of  spaolfic  diagnostic  alamant  mixas. 
Tha  mission  data  to  ba  oollaotad  and  considarad  for  ganarating  tha  diagnostic 
raquiramanta  Is  aa  follows: 

0  Mission  soanarios  dafinition  (priorWxad  In  ordar  of  ciitloallty) 

0  Mission  rata/langth 

0  Mission  oparatlon  (continuous  vs.  Intarmittant) 

0  Mission  phasas 

0  Tima  damands  and  oparational  constraints  par  mission  phasa 

0  Subaystam/funotlon  utilization  par  mission  phasa  (survivability  or  safaty 
orHIoal) 

0  Funotlons/failuras  Impacting  psrsonr'al  safaty 

0  Punctlons/falluras  Impacting  systam/aquipmant  safaty  (sustainability  or 
mission  crltioal) 

0  Punetlons/failuras  Impacting  mission  sucoa(.s  (par  mission  phasa). 

A  Hay  diagnostic  paramatar  to  ba  datarmlnad  through  tha  analysis  nf  mission 
raquiramants  Is  tha  maximum  fallura  latanoy  par  oparating  function  fo '  aaoh  mission 
phasa.  This  paramatar  will  driva  tha  fault  datacdon  raquiramants  which,  in  turn,  sarva  as 
tha  basis  for  BIT  daslgn.  Fallura  latanoy  Is  tha  aiapaad  tirr. .  batwaan  fauK  ooourranca  and 
fallura  Indication.  Maximum  fallura  latanoy  is  tha  maximum  albwabla  tima  batwaan  tha 
ocourranoa  of  a  fault  and  tha  reporting  or  "handling*  of  tha  fallura.  As  a  simpllstio  axampla, 
If  a  ftra  control  system  fault  occurs,  and  tha  fire  control  system  function  Is  highly  critical  to 
mission  success,  than  tha  maximum  fallura  latency  will  ba  vary  small  ••  perhaps  axprassad 
In  mlorosaconds  or  nanoseconds.  Tha  fault  detection  (FD)  tima  raqulramant  will  reflect  tha 
failure  latanoy  factor  -■  tharaby  driving  tha  BIT  technique  to  provide  concurrent 
performance  monitoring.  Fault  tolerance  through  redundancy  may  ba  required  or 
oonaidarad.  This  simplistic  axampla  Is  made  more  complex  by  factoring  in  tha  time 
damands  par  mission  phasa  of  tha  fira  control  system.  It  is  made  still  more  complex  by 
factoring  in  oparating  anomalies  and  intarmittants  Into  tha  FD  raquiramants. 

In  tha  definition  of  diagnostic  raquiramants,  it  Is  Important  to  note  that  tha 
diagnostic  capability  Is  made  up  of  tha  Inherent  diagnostic  capability  of  tha  prime  system 
(active  arrays  are  fault  tolerant),  as  wall  as  added  diagnostic  alamants.  It  Is  tharafora 
Important  that  diagnostic  analysis  ba  Integral  to  tha  prime  weapon  system  anginsaring 
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TRANSLATING  MISSION  REQUIREMENTS  REQUIREMENT  #2.1 


prooMS,  sinc«  ptrformanot  and  support  paramatara  can  no  longar  ba  laolatad  from 
daaign. 


Tha  prima  oonfiguratlon  rapraaanta  a  parformanoa  oapablllty.  Tha  mlaalon 
raqutromants  can  ba  ralatad  diraotly  to  tha  configuration  by  analysis  of  tha  bahavlor  of  tha 
utillxad  oonfiguratlon  Itams  ovar  tha  tima  damands  Impoaad  by  mission.  A  raprasantatlon 
of  parformanoa  ovar  tIma  intagratas  tha  "lllty*  maasuras  and  oan  ba  aaslly  prasantad  to 
managamant  for  setting  raqiJfi'smants.  This  maasura  Is  rafarrad  to  as  P.  (Parformanoa 
time  dapandanoy).  P»  oan  b<  .aloulatsd  and  plotted  using  aquations  for  mission  rallablllty 
In  MIL-STD-756B. 

Operational  oonatraints  also  must  ba  addressed.  Tha  ohaokllst  below  presents 
tha  operational  data  to  ba  oollaotad  and  oonsidarad  In  diagnostic  raquiramants  analysis. 

0  Environmental  conditions  (tamparatura,  rain,  dirt,  salt  spray,  ato.) 

0  Operating  locations  (dispersed  vs.  oantrallzad) 
(ramota/aooaasibla/lnaocassibio) 

0  Space  limitations  (for  parsonnai  and/or  teat  equipment) 

0  Mobile  or  fixed  maintananca  facilities 

0  independent  operation  or  part  of  a  battle  group 

0  Manpower  constraints  (number  and  skill  levels). 

Tha  constraints  under  which  a  weapon  system  must  operate  must  ba  identified 
and  evaluated  In  terms  of  tha  Impact  on  testability  raquiramants.  System  design  and 
supportablllty  factors  must  taka  Into  account  these  constraints.  Operating  constraints  will 
often  drive  tha  diagnostic  strategy  to  use  of  embedded  versus  external  test  rasouroas. 

Prima  System  ArohItaetura/ConSguratlon 

Data  must  ba  oollaotad  on  tha  arohitaotura  and  configuration  altomatlvaa  of  the 
prime  system  to  ba  developed  with  rsspaot  to  partitioning,  Intaroonnaotlons  and  flow  as 
Input  to  tha  testability  raquiramants  analysis.  Tha  arohitaoturas  under  oonaidaratlon  will 
have  Inherent  oharaotarlstlos  which  may  support  or  Impede  diagnostics.  Tha 
parformanoa  oapablllty  of  altarnatlva  prime  system  arohitaoturas  must  ba  evaluated 
against  tha  mission  raquiramants,  tima  phases  and  equipment  utillzatlon/damands. 

It  is  useful  for  this  evaluation  to  plot  curves  of  capability  vs.  tima  damands 
Imposed  by  tha  mission.  Tha  resulting  (Parformanoa  ovar  Tima)  ourv'a  can  include 
resource  constraints  (spares,  personnel)  and  operational  constraints  (maximum  allowable 
repair  time). 
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TRANSLATING  MISSION  REQUIREMENTS _ REQUIREMENT  #2.1 

The  following  prime  system  configuration  data  should  be  collected  for  Input  to 

this  step: 

0  Work  Breakdown  Structure  (MtL-STD-88 1 ) 

0  List  of  government  furnished  equipment/ 

off-the-shelf  equipment/  non-developmental  Herns 
(for  above,  Item  or  candidate  Hem) 
o  Prime  system  archHeoture  aHematives 
0  Initial  failure  rate  projections  and  characterization 
0  Fault-tolerant  or  redundant  functions 
0  Technologies  to  be  used  (H  known) 

0  Level  of  Integration  vs.  autonomy. 

Based  upon  analysis  of  archHeotures  under  consideration,  high-level  diagnostic 
opportunities  should  be  Identified.  This  Includes  Incorporation  of  a  test  and  maintenancs 
bus,  fault-tolerant  design  coordination,  system-level  diagnostic  resouross  •  such  as  data 
aoquisHion/  ‘"'lection  subsystems  or  embedded  adaptive  diagnostic  subsystem  and  use  of 
standard  di  <noatio  connections  and  Interfaces. 

Diagnostic  Inputs  must  be  made  within  the  system  engineering  process  prior  to 
the  final  selection  of  the  prime  system  srchHecture. 

Evaluate  Technology  Opportunitlee 

Advanced  diagnostic  technology  opportunity  or  Implications  must  be  Identified 
based  on  f'e  following  areas: 

o  Baseline  comparison  system  major  drivers,  supportablllty  problem  areas, 
targets  of  Improvement 

0  Incorporation  of  LSI,  VLSI,  VHSIC,  expert  system  or  other  advanced  design 
technology  in  system 

o  Need  to  improve  requisite  operational  capability  having  no  prior  design 
solution. 

Examples  of  advanced  diagnostic  technology  opportunities  which  may  be 
exploHable  on  the  new  system  include; 

o  Expert  system  based  maintenance  aids 

0  Test  and  Maintenancs  bus  concepts 

o  "Smart"  BIT  techniques 
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0  Adaptive  diagnostic  subsystems 
0  Prognostics  concepts 
0  Automated  tect  iriical  information  authoring 
0  Advanced  packaging  technic'jes 

0  Advanced  instrumentation  (stimulus  and  measurement)  technologies 

0  Automatic  capture  of  CAD  data  for  diagnostics  generation. 

Upon  determination  of  advanced  technology  applications,  Inputs  must  be  made 
to  the  design  engineerirtg  effort  regarding  design  constraints  related  to  the  above 
concepts. 

Dlagnoatto  Elenwnt  Conatrainta 

“  order  to  define  specific  diagnostic  characteristics  and  requirements  of 
the  system  or  to  further  "close  In*  the  envelope  within  which  tradeoffs  are  conducted, 
diagnostic-related  constraints  are  established.  This  Includes  constraints  placed  on 
built-in  test  design  attributes  and  functions,  testability  constraints  and  test  equipment 
constraints.  This  may  also  Include  broader  dlaqnostlc-related  constraints,  such  as 
page  count  of  tsohnloal  Information  or  maintenance  technician  skill-levels.  These 
constraints  are  driven  by  mission  requirements,  design,  operation  and  support 
characteristics,  or  standardization  policies  imposed. 

Sample  diagnostic-related  constraints  are  provided  below. 

Driving  System  Requirement  Resulting  Diagnostic  Constraint/Requirement 


Test  Equipment  Size/Weight 

BIT  Interface  Planned  Maintenance  Duty 

Cycle 

Redundancy 
Fault-Tolerant  Design 


Standard  Diagnostic  Connectors 
Controllability,  Observability 
Interface  to  UUT 
Interface  Design/Protocol 
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QFE 

PMlan  Characf  rlatlcs 

Powsr  Availability 
Syatam  Waight 
Systam  SIza 


Memory  Limitation 
Oparating  Syatam  Char. 
Coat 


Bit  Daaign/Capabilltlea 


BIT  Powar  Conaumptlon 

BIT  and  Taat  Connector  weight 

Volume  of  BIT  CIroultry  and  Taat  Connaotora 

(Real  aetata  available  for  BIT  circuitry) 

Volume  required  for  Increaaed  modularity 
Memory  aliooatable  to  BIT  funotlona 
Software  BIT  function  conatrainta 
Coat  of  additional  hardware  required  for  BIT 
and  taatablllty 


Eetabllah  Diagnoatle  Oblaotlvaa 

Analyala  of  weapon  ayatam  data  aaoertained  muat  be  performed  to  Identify 
diagnoatio  objaotivea  baaed  on  ayatam  raquiramanta.  DIagnoatIo  objaotivaa  to  be 
contidared  Include: 


o  BIT  PD/FI  raquiramanta  to  aupport  preliminary  maintenance  concept 

•  Repair  Timaa 

•  Reconfigurability 

•  Deferred  Maintenance 

•  Fault  Tolerance 

0  BIT  requirementa  to  aupport  ayatam  confidence  chaoka 
o  Requirement  to  deal  with  Intarmittant  faulta  or  ope  ’ational  anomaJlee 
0  Prime  ayatam  arohitectura  teatability  opportunitlaa 
0  QFE  teatability  faotora/conatrainta 
o  Requirementa  for  vertical  teatability. 


Examplaa  of  typical  objaotivaa  to  be  eatabllahed  at  thia  point  are  provided 

below. 


DRIVINO  SYSTEM  FACTOR 
Maximum  Acceptable  Failure  Latency — 
Mlaaion/Safaty  Critical  Function- — s» 

MTTR,  Sparea - iw 

Manpower  and  Skill  Levela - 

QFE  Conatrainta - 

Fault-Tolerant  Deaign  Coordination — 

2-Level  Maintenance - 

Life  Cycle  Coat  Priorities - aa> 

Minimize  RTOK  Rate  Between - =» 

Maintenance  Levels 


gAMPie 

DIAGNOSTIC  OBJECTIVE 
Faun  Detection  Time 
Performance  Monitoring 
FauK-laolatlon  Level 
BIT  Faun-laolatlon  Level 
System-Level  BIT  Requirements 
Performance  Monitoring 
Ambiguny  Qroup  Size 
Reliance  on  Embedded  Diagnostics 
Utilize  Compatible  Test  Equipment, 
Techniques,  Tolerances 
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Initial  diagnostic  requirements  result  from  analysis  of  weapon  system 
oharaoterlstlcs,  prioritized  as  needed,  on  diagnostic  elements.  It  Is  convenient  to  partition 
the  diagnostic  elements  as  embedded  and  external. 

Some  of  the  tradeoffs  to  be  made  for  generating  embedded  and  external 
diagnostic  requirements  Include: 

0  Functions  and  'evel  of  builMn  test  vs.  external  diagnostics 

0  Functional  vs.  parametric  testing 

0  BullMr  teat  fault  detection 

'  Concurrent  performance  monitoring 
-  Periodic  BIT  routines 
•  Operator  Initiated  BIT  routines 

0  Level  of  diagnostic  capability  at  each  level  of  maintenance  (e.g..  detect  95% 
of  faults;  Isolate  to  3  LRUs;  within  30  mlnutss,  utilizing  a  speolflo  diagnostic 
resource). 

0  Diagnostic  elements  to  be  uued  at  each  level  of  maintenance  (e.g.,  test 
equipment,  technical  Information  and  maintenance  aids,  training  and  skill 
Isvels). 

Once  the  level  of  liullt-ln  test  is  established,  a  maintenance  workload  generated 
by  operational  and  failure  rate  data  can  be  projected.  At  this  point,  detailed  tradeoffs  can 
be  performed  regarding  the  optimization  of  testability.  Including  level  of  diagnost'c 
capability  at  each  level  of  rralntenance,  and  the  effectiveness  and  efficiency  of  the  mix  of 
diagnostic  elements  to  be  used  at  each  level  of  maintenance.  A  basollne  comparison 
system  Is  used  to  project  failure  data.  The  requirements  that  need  to  be  established  are 
outlined  below: 

Embedded  DIagnostle  Requirements 

o  SIT  requirement  for  monitoring  of  mission-critical  functions  and  functions 
affecting  personnel  safety  (derived  from  maximum  allowable  failure  latency) 

0  BIT/SIT  requirements  to  support  operational  constraints 

o  Requirement  to  deal  wHh^handle  intermittents/anomalles 

0  BIT/SIT  requirements  to  support  system  confidence  checks 

0  Prime  system  architecture,  testability  opportunities,  and  QFE  testability 
factors/constralnts 
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o  BIT  r«quir6m«ntt  to  support  proliminary  maintsnsnce  concept,  based  on: 

>  Level*of>ropair  analysis 

-  Manpower  available 

'  Skill  levels  avallable/required 

•  Deter  sd  maintenance  goals 

-  Repair  times  (driving  fault  Isolation  time) 

•  Sparing  concepts  (driving  fault  Isolation  levels) 

•  Standardization  requirements/goals  (test  equipment,  personnel 
qualifications) 

o  Requirement  to  provide  handshake  to  external  diagnostic  rssources  (vertical 
testability,  vertioal  diagnostics). 

External  Diagnostic  Requirements  (Support  Equipment,  Teohnical  Data,  and 
Personnel) 

OPERATtONAiyoRQANIZATIONAL  MAINTENANCE  LEVEL: 

0  Requirement  for  elements  to  optimize  Interfaoe/utilizatlon  of  embedded 
diagnostio  elements 

0  Define  FD/FI  functions  to  satisfy  0>Level  maintenanos  operations  (driven  by 
Inputs  from  operational  constralitts  and  preliminary  maintenance  concept), 
based  on: 

•  Minimization  of  unnecessary  removals 

•  Mobility  requirementa/space  available 

•  Level*of*repair  analysis 

•  Sustainability  (spares  replenishment) 

•  Manpower  available 

•  Skill  levels  available/required 

-  Repair  times 

•  Sparing  concepts 

•  Standardization  requirements/gdals 

0  0-Lovsl  technioal  Information  (Including  maintenance  aids) 

0  0-Levsl  test  equipment 

•  Manual  tost  equipment 

-  Automatic  test  equipment  and  test  programs 

-  Portable  maintenance  aids 

0  0‘Level  training  requirements  to  support  skills  required 
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•  On>th«>job  training 

•  Formal  school  training 

0  O-Loval  data  aequisitlon/collaction  system  (and  data  management) 

0  Requirements  to  provide  0*Level  handshake  to  LLevel  diagnostic  elements 
(vertical  testability,  vertical  diagnostics) 

INTERMEDIATE  MAINTENANCE  LEVEL: 

0  Define  FD/FI  functions  to  satisfy  l-Level  maintenance  operations  based  on: 

•  Minimization  of  unnecessary  removals 

•  Mobility  requirementa/space  available 

•  LeveLof-repalr  analysis 

•  Sustainability  of  spares  pipeline 

•  Manpower  available 

•  Skill  levels  avallable/required 
>  Repair  times 

•  Sparing  eonoepta 

•  Standardization  requirementa/goals 

0  l-Level  technical  Information  requirements  (Including  maintenance  aids) 

0  l-Level  test  equipment  requirements 

-  Manual  test  equipment 

-  Automatic  test  equipment  and  test  program  seta 

0  l-Level  training  requirements  to  support  skills  required 

-  On-the-job  training 

-  Formal  school  training 

0  l-Level  data  acquisition,  collection,  management,  analysis,  processing 
system  requirements 

0  Requirement  to  provide  i-Level  handshake  to  Depot-Level  diagnostic 
elements  (vertical  testability) 

DEPOT  MAINTENANCE  LEVEL: 

0  Define  FD/FI  functions  to  satisfy  Depot-Level  maintenance  operations, 
based  on: 
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•  L«vtl-of-rapair  analysis 

•  Sustainability  of  sparas  pipallna 

•  Manpowsr  availability 

•  Skill  lavols  avaiiabia/raquirsd 

-  Rapair  timas 

•  Sparing  oonoapts 

•  Standardization  raqulramants/goals 

0  D'Lsval  taohnioal  information  raquiramants  (Including  maintananoa  aids) 

0  D’Laval  tast  aquipmant  raquiramants 

•  Manual  tast  aquipmant 

•  Automatic  tast  aquipmant  and  tast  program  sats 

0  D'Lsval  training  raquiramants  to  support  skills  raqulrad 

•  On-tha-Job  training 

-  Formal  school  training 

0  D-Lsval  maintananoa  data  acquisition,  oollaotlon,  analysis,  prooassing 

0  Raquiramant  to  captura  and  utiliza  factory  tast  rasourcss  and  rasults  and/or 

data  for  Oapot  usa  (vartloal  tastidsiiity,  vartloal  diagnostics). 

SInca  tha  ovarall  diagnostic  capability  must  bs  definad,  quantiflad,  dasignad, 
avaluatad,  ate.,  It  Is  bast  dafinad  as  a  "diagnostic  subsystam."  This  subsystam  can  ba 
brokan  down  Into  its  oomponant  parts  and  dafinad  In  a  typa  of  format.  This  format  will 
faollltata  tha  hlararchloal  allocation  and  diagnostic  mix  optimization  process  bacausa 
function  and  cost  paramatars  can  ba  quantitativaiy  asslgnad  to  aaoh  alamant.  AKamatlva 
diagnostic  subsystems  may  than  ba  aasity  aynthasizad  and  avaluatad. 
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CHECKLIST 

Ei  Hat  tht  Inhtrtnt  dlognottie  capability  of  tht  prlmt 
p/tttm  archittcturt  Bttn  Included  In  the  analyele? 

□f  Hove  the  requiremente  been  generated  for  both 

embedded  and  external  dlagnoetlce?  Are  they  feaelble 
and  Implementable? 

Ei  Hae  the  mieelon  data  been  defined  and  utilized 
In  the  dlagnoetlc  requiremente  generation? 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

PSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

AcnvmEs 

CONTRACT 

AWARD 

DIAGNOSTIC 

ACTIVITIES 

zs  zs 

ALLOCATION  UPDATE 

PIAGNOSTIQ  ACnm 

Alloottlon  of  diagnoitio  raqulramantt  from  tha  ayatam  loval  to  tha  aubayitam 
and  unit  laval  la  raquirad  In  ordar  to  aaaign  apaoMoatlon  valuaa  to  aaeh  configuration  Itam 
which  forma  part  of  tha  waapon  ayatam.  Tha  allocation  prooaaa.  which  la  normally  dona 
by  tha  contractor,  ahall  aiaura  that  tha  waapon  ayatam  diagnoatlo  raquiramants  and  tha 
conatralnta  on  tha  diagnoatlo  aubayatam  ara  not  violated  during  tha  How  down”  prooaaa. 

pr\9fiiP.yHi 

Initial  allocation  of  diagnoatlo  raquiramanta  to  lowar  ayatam  lavala  muat  ba 
baaad  upon  tha  tima  damanda  placed  upon  tha  ayatam  configuration  by  tha  mlaalon 
raquiramanta. 

After  tha  Initial  aat  of  diagnoatlo  raquiramanta  haa  bean  defined,  a  diagnoatlo 
mix  la  poatulatad  from  tha  aynthaalzad  diagnoatlo  aubayatam  altarnativaa  In  ordar  to 
Implamant  tha  Initial  aat  of  diagnoatlo  raquiramanta. 

Wharaaa  tha  Initial  diagnoatlo  raquiramanta  ara  driven  by  mlaalon  tima 
damanda,  tha  optimization  of  tha  diagnoatlo  alamant  mix  la  driven  by  raaouroa  conatralnta. 
Simply  atatad,  tha  raquiramanta  generation  prooaaa  Indloataa  what  la  needed  and  tha 
diagnoatlo  mix  generation  prooaaa  Indloataa  tha  moat  affordable  aolutlona.  A  rlaK  analyala 
performed  during  tha  aubaaquant  phaaaa  of  ayatam  development  confirm  tha  aolutlona  aa 
faaaibla.  It  la,  tharafora,  Important  to  note  that  tha  allocation  procedure  la  a  partial  atop  In 
tha  development  of  a  diagnoatlo  ayatam.  During  tha  diagnoatlo  alamant  optimization  and 
daaign  prooaaa.  It  may  ba  coat  affaotlva  to  reallocate  tha  diagnoatlo  raquiramants  In  order 
to  aohlava  bettor  implamantatlona  with  raapaot  to  raaouroa  constraints.  Many  of  those 
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tradtofft  art  drlvan  by  both  toohnoiogy  and  tha  aoquialtlon  businosa  dacislona  that  ara 
mada  for  aaoh  waapon  ayitam  program.  For  axampla,  alloeatlon  of  a  taatabllity  atratagy 
to  aaoh  tubayatam  may  not  ba  faaalbla  dua  to  tha  axiatanoa  of  many  govarnmant- 
furnlahad  aquipmanta  within  a  particular  weapon  ayatam.  In  thoaa  oaaoa,  a  oantrallzad 
ayatam*laval  taat  approach  may  ba  mora  daalrabla.  A  ahift  In  allocation  from  aubayatam  to 
ayatam  laval  will  prove  affective  In  tha  implamantatlon  of  that  particular  waapon  ayatam 
diagnoatloa. 

To  achieve  thia  flexibility,  tha  allocation  prooaaa  muat  ba  tied  to  tha  ayatam-laval 
rallability  modal.  ThIa  modal  will  contain  tha  allocated  paramatora  with  traceability  back  to 
ayatam*laval  paramatara.  In  thia  way,  aa  tha  program  procaada  from  Concept  through 
Dam/Val  Into  Pull-  Scale  Davalopmant,  each  of  tha  valuaa  can  ba  traded  off  aa  tha 
dlagnoatlc  aubayatam  la  configured  and  optimized  aa  a  raault  of  knowledge  gained  from 
trade  atudlaa. 

QUIDANCl 

A  preliminary  dlagnoatlc  allocation  ahould  ba  prepared.  Tha  allocation  ahould 
Include  all  dlagnoatlc  alamanta  and  oonaldaratton  of  all  maintenance  lavala.  Tha  allocation 
of  dlagnoatlc  goala/valuaa  ahould  ba  acoompllahad  through  tha  application  of  atructurad 
procaaaaa,  baaed  on  taak  daacriptlon  and  guidance  provided  within  applicable  military 
atandarda.  Tha  taaka  and  guidanca  paragrapha  that  define  tha  allocation  prooaaa  to  ba 
employed  ara: 


MIL-STD-40g 

Taak  10.2.3 

Allocation 

MIL-STO-786 

Taak  202 

Reliability  Allocation 

MIL-STD470 

Taak  202 

Maintainability  Allocation 

MIL-STD-2166 

Taak  201 

Taatabllity  Raquiramanta. 

MIL-STD-490  addraaaaa  tha  entire  allocation  prooaaa  for  all  performance  and 
daaign  raquiramanta.  Tima  raquiramanta,  which  ara  praraquialtaa  for  a  function,  or  aat  of 
funotlona,  affecting  mlaalon  auooaaa,  aafaty,  and  avallablilty  arc  derived.  It  la  eaaantlal  that 
tha  dlagnoatlc  raquiramanta  ba  derived  In  conjunction  with  tha  entire  waapon  ayatam 
allocation  prooaaa.  Reliability  and  maintainability  allooatlona  ara  derived  aa  part  of  tha 
overall  waapon  ayatam  allooatlona.  Thua,  they  have  a  direct  affect  on  tha  dlagnoatlc 
allooatlona.  Failure  rataa  and  repair  rataa  ara  tha  drlvara  in  aatabllaiilng  dlagnoatlc 
allocatlona.  However,  other  conaldaratlona  dealing  with  aafaty  monitoring,  raadinaaa 
monitoring,  and  loglatio  funotlona  all  play  a  part  in  thia  prooaaa.  Tha  allocation  of 
dlagnoatlc  raquiramanta  la  uaually  performed  aa  part  of  tha  overall  LSA  prooaaa.  Cloaaiy 
tied  to  tha  LSA  prooaaa  la  tha  aatebllahmant  of  taatabllity  raquiramanta,  Including 
performance  monitoring,  BIT,  taat  equipment,  dlagnoatlc  taat  pointa,  etc. 
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It  Is  Important  that  this  allocation  procaas  Ineludas; 

0  FD/FI  oovaraga  for  all  (100%)  faults  known  or  axpeoted  to  occur  at  aach 
maintananca  laval,  and 

0  Quantification  of  all  diagnostic  alamants. 

FIgura  3  la  a  Notional  Diagnostic  Allocation  Spaoifloatlon,  which  axampllflas 
thasa  oonoapts.  This  allocation  process  is  also  olosaly  tiad  to  tha  optimization  procass 
(Raquiramants  #2.3).  It  Is  Important  that  this  allocation  procass  includes  quantification  of 
all  diagnostic  alamants.  For  Instanoa,  tha  tima  to  aooaas  technical  Information  can 
datarmlna  whether  paper  or  alaotronlc  delivery  of  technical  Information  is  raquirad.  Formal 
training  time  may  Influence  tha  need  for  on*tha’)ob  training  aids. 

This  systam-laval  allocation  forms  tha  basis  for  tha  System  Specification 
discussed  under  Requirement  #1.2.  It  also  Is  followed  by  allocation  down  to  subsystem 
and  Ham  levels. 

Alloeata  Raquiramanta  to  Item  Development  Spaeltloatlon 

Systsm*laval  diagnostio  raquiramants  are  allocated  down  to  subsystem  and  Item 
levels  for  tha  purpose  of  tha  development  of  those  Items.  Diagnostic  requirements  for 
Configuration  Items  (Cl)  support  two  distinct  requirements;  system  test  (primarily  BIT)  and 
shop  test  (ATE  and  QPETE). 

Quantitative  testability  requirements  for  each  Configuration  Item  are  allocated 
from  system  diagnoatic  requirements  based  upon  FMEA  data,  relative  failure  rates  of  CIs, 
mission  orltioalHy  of  the  CIs,  what  Is  achievable  for  each  Cl  or  other  specified  criteria.  The 
failure  detection  level  of  the  Cl  Is  weighted  by  the  Hems’  failure  rate  to  ensure  that  system* 
level  fault  deteotlon  capability  Is  achieved.  Table  4  Is  an  example  of  an  allocation  of  a 
system*  level  BIT  fault  detection  requirement  which  Is  allocated  to  five  configuration  Hems. 
The  table  shows  three  alternative  FD  allocations  which  meet  the  system*  level  BIT  PD 
requirement  of  95%. 
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TABLi  4  8AMPLB  ALLOCATION  OF  M%  BIT  FO  RBQUIRIMBNT 


CONFIQURATION 

ITRM 

x^o•* 

FD  ALLOCATION 

#1 

FD  ALLOCATION 
«9 

FD  ALLOCATION 

#3 

A 

100 

.06 

.90 

.08 

B 

10 

.96 

.60 

1.00 

0 

SO 

.96 

.70 

.98 

D 

200 

.96 

.99 

.00 

1 

100 

.96 

.99 

.09 

8YBTBM 

460 

.96 

.96 

.98 

Tht  BIT  ptrlormAnoB  captbillty  And  ttiUbillty  oharaotiriitios  of  QFE  portion!  of 
th*  tytttm  should  bs  oonildorsd  In  tho  slloostlon.  For  sxsmpls,  sisums  s  QFE  Itsm  hit 
only  70%  BIT  ftult*dstf  etion  ospablllty.  In  ordt r  to  sooompilih  ths  95%  iystsm*!# vsl 
ospsbillty  rsquirtd  In  ths  sbovt  txampls,  ths  slloostlon  distribution  must  tsKs  into  scoount 
ths  ospsbillty  of  ssoh  of  ths  Itsms  whioh  msks  up,  or  oontributs  to,  ths  lyitsm  IsvsI.  Ths 
ospsbillty  of  ths  QFE  thsn  so rvss  si  s  oonstrsint  in  ths  slloostlon.  in  ths  sbovt  txampit, 
glvsn  thst  Itsm  C  Is  QFE  with  70%  BIT  fsultKfstsctlon  ospsbillty,  tho  FD  slloostlon  schtmo 
#2  Is  s  rtsi  world  sitsmstivs  snd  tho  othsri,  #1  snd  #3  srs  not. 

Shop  tost  roquiromonts  sro  dotormlnod  by  how  tho  Cl  Is  furthsr  psrtitlonod,  If  at 
all,  Into  Units  Undor  Tost  (UUT).  DIagnootIo  roquiromonts  for  osoh  UUT  should  bo 
inoludsd  In  ths  spproprloto  Cl  Dovoiopmont  Spooifiostlon.  Thoso  psromotors  sro  not 
slloostod  from  ths  syotom*lsvol  roquiromonts,  but  rsthor  art  drivsn  by  tho  diagnostic 
oonoopt  of  off'lino  tost  roquiromonts  of  tho  Configuration  Itomo. 

In  many  digital  systsmo,  bulIMn  tost  is  implomontod  In  wholo  or  In  part  through 
software.  Hors,  disgnostio  roquiromonts  will  appear  In  a  Computer  Program  Configuration 
Item  (CPCI)  dovoiopmont  spsolfloatlon.  Ths  CPCI  may  bo  dodlostou  to  tho  built-in  toot 
function  (I.O.,  a  msintsnanoo  program)  or  may  bo  a  mission  program  which  contains  tost 
funotlono. 
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CHECKLIST 

EST  Are  all  diagnostic  elements  quantitatively  defined? 

Were  eonetraints  allocated  to  all  diagnostic  elsmsnts? 
Kt  Were  constraints  assigned  to  all  maintenance  echelons? 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

AcnvmEs 

A  z:.  A 

- - - -  PREUMINARY 

CONTRACT  DESIGN 

AWARD 

DIAGNOSTIC 

ACTMTIES 

S  S  A 

OPTIMIZE  UPDATE  UPDATE 

DIAG.  MIX  OPTIMIZE  MIX 

DIAGNOSTIC  ACTIVITY 

Qivtn  tht  ailooatlon  of  diagnottio  roquiramanta  to  tha  aubayatam  and  unit  laval, 
tha  "dlagnoatlo  aubayatam"  muat  ba  dafinad  aa  part  of  tha  ovarall  waapon  ayatam 
apaolfloatlon,  Tha  raaulting  diagnoatio  aubayatam  includaa  both  ambaddad  and  axtarnai 
aupport.  Extarnal  aupport  muat  ba  dafinad  at  all  lavale  of  maintananoa  and  Includaa 
tachnical  Information,  aupport  aquipmant,  and  parsonnal  numbara  aiHl  akill  lavala. 

PROCRDURE 

Tha  starting  point  for  davaloping  tha  diagnostic  subsystam  la  tha  ganaratlon  of 
a  diagnostic  aubayatam  proflla  from  tha  waapon  syatam  charactarlstics  and  prioritlas. 
Each  of  tha  diagnostic  alamanta  will  hava  a  diffaring  Impact  on  tha  waapon  systam 
charactarlstics.  For  axampla,  a  high  priority  constraint  on  logistic  support  would  favor  a 
high  dagraa  of  ambaddad  diagnostu a.  On  tha  othar  hand,  constraints  on  parsonnal  may 
favor  technical  Information  systams  with  a  high  dagraa  of  artificial  Intalllgance.  Oparatlonal 
constraints,  which  ara  common  across  the  military  sen/lces,  are: 

0  Environmantal  conditions  (tamparature,  rain,  dirt,  salt  spray,  ate.) 

0  Operating  locations  (dispersed  vs.  centralized) 
(ramota/accasslble/lnaccesslbla) 

0  Space  limitations  (for  personnel  and/or  test  equipment) 
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0  Mobil#  or  fixod  maint#n#no#  faolllli## 

0  lnd#p#nd#nt  operation  or  part  of  a  battio  group 

0  Manpower  constraints  (number  and  skill  levels). 

Analysis  of  the  weapon  system  oharaoteristlcs  in  terms  of  their  Impact  on  the 
support  elements  will  generate  various  support  element  diagnostic  profiles. 

The  diagnostic  profiles  will  portray  various  mixes  of  diagnostic  elements  for 
different  weapon  system  characteristics  and  constraints.  Each  of  the  diagnostic  element 
profiles  Infers  a  diagnostic  subsystem  which  car.  be  built  and  delivered  with  the  weapon 
system.  The  optimization  Issue  Is  the  aelctctlon  of  a  diagnostic  subsystem  which  can  be 
implemented  at  low  risk  and  which  meets  the  requirements  allocated  to  system, 
subsystem,  and' unit  level. 

The  key  to  optimization,  therefore.  Is  the  development  or  synthesis  of  various 
alternative  diagnostic  subsystems  based  upon  the  weighted  diagnostic  eioment  profiles. 
This  Is  an  engineering  task  and  represents  an  Important  aspect  in  the  overall 
developmeut  of  a  diagnostic  capability  for  the  weapon  system.  By  generation  of  a 
diagnostic  subsystem,  early  In  Concept  Exploration,  the  overall  dealgn  Integration  of 
support  and  prime  design  elements  will  be  achieved.  During  the  Dem/Val  and  Full-Scale 
Development  Phases,  the  diagnostic  subsystem  is  refined  based  upon  trade  studies. 

The  key  Is  to  Identify  the  sensitivity  of  the  various  diagnostic  element  function 
contributions  to  the  overall  life  cycle  costs,  and  to  ensure  that  all  diagnostic  functional 
requirements  are  considered  and  included  as  part  of  the  total  diagnostic  subsystem 
synthesis. 


Each  diagnostic  subsystem  aHemative  synthesized  Is  evaluated  with  respect  to: 

o  Impact  on  Mission  Performance  Over  Time 
0  Impact  on  Resource  Requirements 

-  Acquisition  Cost 
•  Life  Cycle  Cost 

-  Manpower  Requirements 

0  Responsiveness  to  operational  constraints. 

The  evaluation  Is  performed  by  assigning  values  related  to  the  evaluation 
factors  listed  above  to  the  diagnostic  subsystem  or  to  the  elements  of  the  diagnostic 
subsystem. 
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To  ovaluate  tha  raaponalvaneaa  of  the  diagnostic  subsystam  to  mission 
parformanca  raquiras  dafining  tha  spaolfio  configuration  utlllzad  for  a  spacifio  mission. 
Tha  raliability  of  that  configuration  to  dalivar  tha  spaclflad  parformanca  Is  than  avaluatad 
for  tha  tima  intarvals  damandad  by  tha  mlasion  soanarlo.  This  Is  callad  "Intarvals 
raliability Interval  raliability  Is  tha  basis  for  determining  diagnostic  requirements  at  thaaa 
Intarvals  and  is  tha  basis  for  reconfigurability,  deferred  maintenance,  and  parformanoa 
monitoring. 

To  evaluate  tha  rasponsivanaas  of  tha  diagnostic  subsystam  to  operational 
constraints,  tha  operational  constraints  must  be  assigned  qualitative  or  quantitative 
values.  Tha  impact  of  tha  diagnostic  subsystam  charaotarlstics  on  those  values  (tima 
demands)  must  than  be  determined.  This  analysis  Includes  availability  parameters  as 
wall  as  mission  raliability  calculations  based  upon  tha  stated  time  damanda  and 
subsystem  utilization.  Tha  system  reliability  modal  Is  a  vary  affective  and  available  tool 
for  this  analysis. 

To  evaluate  tha  Impact  of  tha  diagnostio  subsystam  on  resources,  cost  factors 
must  be  assigned  to  each  element  of  tha  diagnostic  subsystam.  Non*raourrlng 
(development)  and  recurring  (production  and  support)  costs  must  be  considered.  The 
manpower  requirements  associated  with  the  alternative  diagnostio  subsystems  must  be 
evaluated.  Spaolfio  program  existing  ICC  models  should  be  used  In  this  analysis.  Data 
Items  should  be  standardized  wherever  possible. 

The  cost  deltas  assoolated  with  alternatives  must  be  evaluated  with  respeet  to 
the  off-line  maintenance  workload  costa  and  effiolenoles  generated  by  the  alternative 
embedded  diagnostic  subsystems.  A  key  diagnostic  element  driving  workload  Is 
ambiguity  group  size  and  RTOK  rates. 

Baaed  upon  the  evaluations  performed,  the  optimum  diagnostic  subsystem 
alternative  la  seleoted  and  the  weapon  system  diagnostic  concept  Is  established  and 
documented.  The  diagnostic  concept  Includes  prime  system  arohiteotura  considerations, 
BIT  requirements  at  the  system  and  aubaystem  levels,  test  equipment,  technical 
information  and  personnel  and  training  requirements  for  each  level  of  maintenance.  The 
diagnostic  function  of  each  element  must  be  clearly  and  quantitatively  defined  as  a 
diagnostio  requirement. 

Utilizing  the  above  procedure,  the  result  of  the  optimization  process  Is  the 
development  of  a  diagnostio  subsystem  early  In  Concept  Exploration.  This  parallels  the 
development  effort  for  radar  subsystems,  fire  control  subsystems,  etc.  The  diagnostic 
subsystem  becomes  a  weapon  system  attribute  early  in  Concept  Exploration  and 
continues  to  evolve  during  subsequent  program  phases. 
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GVIPAWffie 

RADC  Itsuad  th«  report,  Tools  for  integratsd  Dlagnottles”  (RADC‘TR-8e-105), 
which  •stablishsd  criteria  for  developing  an  optimized  diagnostic  mix  of  bullt*ln,  external, 
and  manual  testing  resources  for  an  electronic  system.  As  of  the  publication  date  of  this 
document,  there  Is  no  formal  algorithm  for  defining  an  optimized  diagnostic  mix.  A 
methodology  for  performing  diagnoatio  optimization  will  be  a  product  of  the  RADC 
Automated  Testability  Decision  Tools  Program,  which  will  be  completed  and  published  In 
mld>1990. 


A  generic  hierarchical  view  of  a  diagnostic  subsystem  which  Includes 
engineering  and  program  management  disciplines  as  well  as  embedded  and  external 
support  elements  Is  Included  below  to  serve  as  guidance  for  the  contractors.  This 
Indentured  diagnostic  subsystem  breakdown  will  allow  costing  by  the  contractor  for 
various  alternatives  proposed  to  satisfy  the  diagnostic  requirements  which  have  been 
allocated  at  all  system  levels.  As  experience  data  Is  accumulated  on  diagnostic 
subsystem  effeotlveness  and  cost.  It  will  be  possible  to  predict  many  of  these  values  early 
In  Concept  Exploration  using  the  diagnostic  profile. 

DIAGNOSTIC  8UB8Y8TSM  HIBRARCHY 

I.  PROGRAM  MANAQBMBNT/ENQINBBRINQ 

A.  Requirements  Analysis 

B.  Diagnostio  Design  8  Analysis/Assessment 

C.  System  Integration  &  Test 

D.  Maturation  Program 

II.  BMBBDDBO  DIAGNOSTIC  BLBMBNT8 

A.  Systom«Level  Diagnostic  Elements 

1.  8ystem*Level  Diagnostic  Hardware 

a.  Teat  and  Maintenance  Bus 

b.  Sensors/Monitors 

c.  Diagnostic  Panel/Display 

d.  Embedded  ATE 

2.  System*Level  Diagnostic  Software 

a.  Status  Monitoring 

b.  Self  Test/Expert  Systems 

c.  Prognostics 

d.  Reconfigurability 

3.  Diagnostics  Information  System 
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B.  Subsystem  Diagnostics 

1.  Subsystem  "A"  BIT 

a.  BIT  Hardware 

1 .  On  Chip 

2.  On  Printed  Circuit  Board 

b.  BIT  Software  &  Firmware 

c.  Interface  to  T&M  Bus 

2.  Subsystem  "B*  BIT  (Radar),  etc. 


III.  BICTBRNAL  DIAGNOSTIC  BLBMBNTS 

A.  0-Level  Diagnostics 

1 .  Technical  Information 

a.  Maintenance  Alda 

b.  Paper-B«aad  Manuals 
0.  Diagnostic  Data  Base 

2.  Test  Equipment 

a.  Manual  Test  Equipment 

b.  Automatic  Test  Equipment 

1.  ATE  Hardware 

2.  Diagnostic  Software 

a.  Expert  Systems 

b.  Test  Program  Sets  (TPS) 

3.  ATE/ILS 

3.  Trained  Personnel 

a.  Manpower 

b.  Skills 

1 .  Formal  Training 

2.  On-The-Job  Training 

4.  Diagnostic  Data  Collectlon/Anaiysls  Systerh  (MIS) 

B.  I-Level  Diagnostics 

1 .  Technical  Information 

a.  Maintenance  Aids 

b.  Paper-Based  Manuals 
0.  Diagnostic  Data  Base 
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2.  Tttt  Equipment 

a.  Manual  Taat  Equipmant 

b.  Automatic  Taat  Equipmant 

1.  ATE  Hardwara 

2.  TPS 

3.  ATE/ILS 

3.  Tralnad  Parionnal 

a.  Manpowar 

b.  Skills 

1.  Formal  Training 

2.  On-Tha*Job  Training 

4.  Diagnostic  Data  CollaotlorVAnalysIs  Syatam 
C.  D-Laval  Diagnostics 

1.  Tachnioal  Infonnatlon 

a.  Malntananoa  Alda 

b.  Papar<Baaad  ^4anuals 
0.  Oiagno»tlo  Data  Basa 

2.  Taat  Equipmant 

a.  Manual  Taat  Equipmant 

b.  Automatic  Taat  Equipmant 

1.  ATEHW 

2.  TPS 

3.  ATE/ILS 

3.  Tralnad  Parionnal 

a.  Manpowar 

b.  Skills 

1.  Formal  Training 

2.  On-ThS'Job  Training 

4.  Diagnostic  Data  Collactlon/Analysis  Systam 
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CHECKUST 


Ei  Dots  ths  “diagnostic  sub^ttsm“  Includs  oil  maintsnoncs 
Isvsis? 


Ei  Was  ths  optimization  of  ths  “diagnostic  subsystsm" 
psrformsd  by  doing  o  unit  critsria  analysis  or 
various  propotsd  “diognostie  tubtyttsmt“7 


E^  Do  you  hovs  a  rsosonabis  dsgrss  of  csrtointy 
that  ths  chotsn  “diagnostic  subsystsm"  rsprsssnts 
an  optimal  solution? 
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Th«  initial  dlagnottlo  lubiyttam,  ganaratad  to  Implamant  tha  allocatad 
diagnoatio  raquiramanta,  must  go  through  a  thorough  risk  analyaia  during  tha  Dam/Val 
Phaaa.  During  aubaaquant  Full*Soala  Davalopmant,  tha  diagnoatio  aubayatam  la 
optlmlzad  utilizing  raaulta  of  trada  atudlaa.  Tha  initial  diagnoatio  alamant  mix  poatulatad 
during  Conoapt  Exploration  la  analyzad  by  tha  contractor  tor  riak  during  that  phaaa  by 
tachnoiogy  aaaaaamant.  Howavar,  riak  aaaaaamant  can  taka  Into  account  threat, 
taohnology,  raaouroaa,  aohadula,  and  coat. 

PBQCIPUWI 

Tha  procedure  for  performing  riak  analyaia  on  tha  diagnoatio  aubayatam  will 
follow  tha  aama  type  of  aaaaaamanta  conducted  for  riak  analyaia  for  other  weapon  ayatam 
alamanta.  For  example,  tha  riak  aaaaaamant  for  a  radar  will  Include  aaaaaamant  of  Ita 
new  development  oomponanta,  aaaaaamant  of  achadula,  coat  riaka.  and  aaaaaamant  of 
tha  overall  taohnologiaa  Involved  In  tha  development  and  Integration  of  a  total  ayatam  to 
meat  tha  performance  raquiramanta.  Since  the  diagnoatic  aubayatam  will  be  treated  aa  a 
major  alamant  of  a  weapon  ayatam,  tha  aama  procaduraa  ahould  apply  for  it.  Heretofore, 
diagnoatic  aubayatama  ware  not  treated  aa  an  entity  and  riak  analyaia  waa  limited  only  to 
tha  phyalcal  diagnoatio  hardware,  auch  aa  automatic  teat  equipment  and  bullt-ln  teat. 

Riak  aaaaaamant  ahall  Include  tha  laolatlon  within  tha  diagnoatio  aubayatam  of 
all  development  and  non<davalopmant  itama.  For  development  Itama,  waiting  factora  In 
tarma  of  criticality  of  that  Item  ahall  be  aaaignad  and  tha  Itama  ahall  be  categorized  with 
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r«8peot  to  rlik.  For  Itoms  oontidtrod  high  dtvolopmont  risk,  workaroundi  shaii  bo 
dovoiopod  and  trigger  points  for  dooiaiona  on  thoir  impiomontation  ahali  bo  iiatod.  Tho 
risk  analysis  documontatlon  shall  bo  utliizod  to  impact  tho  Statomont  of  Work  for  tho 
Dom/Val  Phase.  During  Dom/Val  hlgh«rlak  items  shall  bo  prototyped  and  domonatratod  to 
tho  satlafaotion  of  tho  Qovommont  Program  Manager. 

QUIPANCB 

Tho  Dofonao  Systems  Management  Coiiogo  has  generated  guidance  on  risk 
management,  which  Includes  risk  assessment,  risk  analysis,  risk  handling  toohniques,  and 
risk  control.  This  guidance  covers  risk  management  for  the  entire  weapon  system,  but  Is 
equally  relevant  to  the  weapon  system's  diagnostic  capability.  Both  risk  assessment  and 
risk  analysis  need  to  be  addressed  early  In  the  development  of  the  weapon  system.  Risk 
assessment  Is  tho  process  of  examining  a  situation  and  Identifying  areas  of  potential  risk. 
Risk  analysis  is  examining  the  change  of  consequences  with  the  modHioation  of  risk  Input 
variables.  At  the  time  this  Contractor  Program  Managert  Quids  was  issued,  the  Defense 
Systems  Management  College  is  publishing  a  risk  management  guide,  which  further 
defines  the  methodology  for  doing  risk  assessment  and  analysis.  Appendix  C  deaoiibes 
several  tools  for  assessing  risk  in  relation  to  time,  coat  and  produciblllty. 

MIL‘STD«1386''1  (Logistics  Support  Analysis)  contains.  In  Tasks  203,  20S,  and 
303  guidance  on  comparative  analysis,  supportabllity  related  design  factors,  and 
evaluation  of  alternatives  for  trade-off  analysis,  all  of  which  are  directly  related  to  the 
weapon  system’s  diagnostic  oapablllty. 

Lessons  learned  have  pointed  to  some  overriding  areas  of  risk  which  must  be 
considered  during  the  initial  risk  analysis  assessment.  These  high-risk  areas  are  listed  in 
the  following  paragraphs: 

The  logistic  support  analysis  process  will  usually  generate  requirements  for 
each  of  the  logistic  elements  comprising  the  oversll  logistic  system.  These  requirements 
are  based  upon  Inputs  regarding  the  level  of  embedded  support  to  be  designed  Into  the 
weapon  system.  The  Logistic  Element  Manager,  given  these  Inputs,  proceeds  to  develop 
sparing  requirements,  support  equipment  requirements,  training  requirements,  etc.  A 
large  program  riak  area  occurs  when  the  promised  embedded  support  area  does  not 
materialize.  It  Is  Imperative,  therefore,  to  oioae  the  loop  between  assessment  during 
Dem/Val  of  the  diagnostic  element  capability  and  that  Impact  on  all  logistic  elements. 

A  second  major  liak  area  occurs  when  a  prime  weapon  system,  which  has  been 
developed  for  a  specific  maintenance  strategy  and  concept,  Is  utilized  In-a  completely 
different  mission  environment.  For  example,  a  major  weapon  system  deployed  In  a  three- 
level  maintenance  environment  may  be  required  to  operate  lor  extended  periods  of  time  In 
a  dispersed  operatiiig  location  with  less  than  full  support.  The  sustainability  and  mobility 
requirements  Imposed  upon  that  weapon  system  may  not  have  been  Included  with 
sufficient  priority  In  the  Initial  analysis  to  develop  capability  for  that  operational 
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environment.  It  Is,  therefore,  imperetive  that  es  pert  of  the  risK  inelyels.  the  assessment 
of  weapon  system  oharaoteristics  and  the  application  of  weapon  system  priorities  be 
reviewed  prior  to  commitment  of  system  development  resources. 

A  third  high  risk  area  worthy  of  special  consideration  is  the  analysis  of  the  very 
large  scale  integrated  circuits  and  very  high  speed  Integrated  oirouits  (VLSI/VH8IC). 
Despite  the  Intensive  use  of  on*ohlp  testing  for  these  devices,  it  Is  Imperative  that  a 
standard  systems  approach  be  generated  by  the  contractor.  Testability  techniques 
Including  signature  analysis  and  boundary  scan  designs  must  be  evaluated  at  the  system 
and  subsystem  level  prior  to  commitment  of  development  resources.  Standardization  by 
the  oontraotor  of  the  embedded  support  arohiteoture  will  eliminate  many  high-risk 
problems  caused  by  multiple  vendors  supplying  different  types  of  on-chip  testing. 

A  fourth  high  risk  area  ooours  when  weapon  system  managers  fall  to 
comprehend  and  implement  the  existing  fielded  maintenanoe  standards  that  are  used  to 
support  the  deployed  system.  For  example,  the  military  has  for  many  years  been 
formalizing  the  use  of  lEEE-STO  716  C/ATLAS  language  for  Depot  maintenanoe.  The 
CASS,  IFTE  and  MATE  programs  have  institutionalized  this  approach.  Despite  this  level 
of  standardization,  many  programs  oompletely  Ignore  this  fact  during  the  Dem/Val  and 
PSD  Phases  of  a  program.  Since  the  targeted  Depot  ATE  has  been  standardized,  It  is 
possible  to  develop  test  programs  starting  with  Paotory-levei  testing  through  integration 
and  lest  of  the  products  that  are  compatible  and  easily  translatable  to  the  fielded 
environment.  This  concept,  called  vertical  oommonallty,  will  mature  the  test  programs  so 
that  during  deployment  the  logistio  system  will  have  a  major  oapabillty  and  remove  many 
of  the  risks  associated  with  transition  from  Interim  oontraotor  support  to  full  government 
support.  Utilizing  expert  system  knowledge  during  these  same  phases  will  allow  the  test 
program  to  contain  levels  of  artiflolal  Inteltigenoe  to  extract  and  utilize  experienoe  data  on 
prior  failures  during  the  Deployment  Phase. 

The  fifth  high  risk  area  is  the  Incorporation  of  government  furnished  equipment 
(QFE)  In  weapon  systems.  Care  must  be  taken  to  ensure  that  the  diagnostic 
requirements  and  capability  are  known  and  verified.  The  Government  Program  Manager 
must  be  Informed  if  the  required  weapon  system  diagnostic  oapabillty  Is  compromised  by 
deflolenoles  In  the  QFE. 

The  sixth  and  final  large  riek  area  Is  the  Integration  and  test  of  the  weapon 
system  prior  to  delivery.  Since  weapon  eystems  have  become  extremely  software 
dependent  and  since  many  weapon  systema  are  multi-mission  In  nature  utilizing  shared 
resources.  It  Is  imperaf've  that  the  Integration  and  test  function  In  a  program  be  utilized  to 
remove  as  muoh  risk  as  possible  from  the  weapon  system.  Integration  of  the  diagnostic 
elements  Into  the  weapon  syetem  will  provide  a  major  "handle”  for  the  oontraotor  In  terms 
of  enhancing  the  Integration  and  test  functions,  if  no  attention  Is  paid  early  In  the  game  to 
this  high  potential  risk,  the  Integration  and  test  functions  will  be  extremely  time  consuming, 
may  not  come  together  on  schedule,  and  may  cause  program  hardships.  If  properly 
achieved,  Integration  and  tost  can  be  streamlined  to  recover  muoh  of  the  upfront  monies 
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REQUIREMENT  #2.4 


•p«nt  on  onhancod  tastabillty  ft aturts.  It  la  tharatora  imparativa  that  thia  araa  ba  givan 
aarloua  attantlon  by  rlak  aaaaaamant  atudlaa  aariy  In  Conoapt  Exploration  and  prooaad 
through  Dam/Val  and  Fult*Soala  Davalopmant. 
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REQUIREMENT  §2A 


CHECKUST 


ESf  Wat  ritk  analytlt  ptrformtd  for  the  tntlrt 
“dtagnoitle  aubtytttm*'  ? 

^  Wtrt  Qdjuttmtntt  plonntd  for  In  thott  cattt  whtrt 
ont  of  tht  dtagnoatle  tltmtnta  falls  to  most 
•xpsetatlona? 

of  Wort  ovallablt  atandordt  takan  Into  account? 

of  Hava  tha  Intagrotlon  ond  taat  riaka  baan  dafinad? 


DESIGN 


REQUIREMENT  #3 


BfflIQL 

3.1  Atsurt  qohttlvtncM  unci  •fflolvnoy  In  th«  design  of  tho  dlognootlo 
capability. 

3.2  Eatabllah  diagnoatio  doaign  orltarla  which  can  be  affaotivaly  utllliad. 
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WEAPON 
SYSTEM 
ACQ.  PHASE 


WEAPON 

SYSTEM 

ACTIVITIES 


OPER. 

REQMTS. 


CONCEPT 

EXPLOR. 


PROD/ 

DEPL 


DIAGNOSTIC 

ACTIVITIES 


DtAONOSnC  PREUM.  DETAIL  FABRICATION 

SPEC.  DESIGN  DESIGN 


Th«  detignvr  Is  rt iponilbit  for  tht  offlolsnt  dsvtiopmsnt  of  an  sfftotlvt 
dlagnostlo  oapabllRy. 


Tha  oohtsivanast  of  tha  diagnostic  dasign  prooass  la  dapandant  upon  tha 
oohasivanass  of  tha  dasign  Information  flow.  Many  factors  affaot  tha  affaotivanass  and 
afflolancy  of  this  Information  flow.  Tha  first  Is  timing  •  What  Is  dona  In  what  saquanoa? 
Tha  saoond  factor  ralatas  to  tha  various  disolpllnas  Involvad  In  tha  dasign  of  tha 
dlagnostlo  capability.  Thasa  diaelpllnaa  ara  oontrollad  by  a  sizaabla  numbar  of  military 
standards,  which  ralata  to  rallablllty,  maintainability,  tastabllHy,  safaty,  human  anglnaarlng, 
softwara,  and  training.  Thasa  standards  tand  to  fraotlonallza  tha  dasign  of  tha  dlagnostlo 
capability,  Inasmuch  as  aaoh  plays  a  significant  part  of  tha  prooasa.  Tha  third  factor  daals 
with  tha  automation  of  tha  dasign  prooass.  Computar-aldad  tools  can  promota  tha 
oohasivanass  and  tha  afflolancy  of  tha  procaas.  Thus,  tha  dasignar  must  undaritand  tha 
oapabllltlas  of  thasa  tools  and  ba  abla  to  apply  tham  affactivaly  and  afflclantly. 
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GUIDANCE 


The  guidance  provided  In  this  section  Is  designed  to  permit  maximum  visibility 
into  the  diagnostic  design  process.  The  designer  must  understand  the  design  process 
flow,  timing,  and  data  requirements  which  must  be  satisfied.  In  addition,  it  is  Important  to 
recognize  that  current  data  Item  procurement  practices  may  not  always  be  supportive  of 
the  design  activity  In-process  data  needs.  At  times,  the  CDRL  and  associated  DID  do  not 
adequately  reflect  these  In-process  needs.  The  high  data  Kern  generation/revision  costs 
generally  experienced  are  strong  motivators  for  delaying  data  Item  preparation  to  a  point 
where  the  design  has  stabilized.  Such  motivation  is  In  direct  conflict  with  the  utilization  of 
the  data  to  make  design  decisions.  A  complete,  detailed  data  submittal  Indicating  that  the 
design  Is  flawed  Is  of  little  use  after  the  design  has  been  completed.  The  guidance  that 
follows  has  been  designed  to  provide  the  necessary  insight  Into  the  design  process,  which 
will  assist  the  designer  In  doing  a  better  job. 

Design  Environment 

The  diagnostic  design  environment  is  an  essential  component  of  the  overall 
diagnostic  design  activity,  which  has  been  established  by  the  contractor  In  response  to 
the  RFP  requirements.  This  environment  encompasses  both  the  implementation 
methodology  and  the  specialty  coordination  associated  with  the  diagnostic  design 
process.  Evidence  of  these  should  be  apparent  In  the  Interim  products  of  the  design 
effort,  which  are  made  available  to  the  government  program  management  function  (at 
both  Informal  in-process  reviews  and  formal  system-level  design  reviews). 

Diagnostic  design  is  characterized  by  its  Iterative  nature  and  a  high  degree  of 
Interdependence  with  the  supportablllty  engineering  specialties  (I.  e.,  reliability, 
maintainability,  Integrated  logistic  support,  testability,  human  engineering,  and  safety). 
The  allocation  of  diagnostic  resources  must  be  based  on  inputs  from  these  disciplines. 
Therefore,  the  timing  and  quality  of  data  Interchanges  must  be  in  accordance  with  the 
program  plans.  A  breakdown  in  data  availability  and  exchange  can  be  responsible  for 
program  delays  and  shortfalls  in  the  fielded  diagnostic  capability. 

The  data  flow  required  to  develop  the  composite  diagnostic  capability  must  be 
responsive  to  the  diagnostic  mix  established  for  the  specific  system  under  consideration. 
Embedded  diagnostic  features,  such  as  built-in  test  (BIT),  built-in  test  equipment  (BITE), 
system  Integrated  test  (SIT),  performance  monitoring,  status  monitoring,  embedded 
training,  embedded  maintenance  aiding,  adaptive  Al-based  diagnostic  systems,  etc.,  are 
an  integral  part  of  the  prime  equipment  design.  Therefore,  the  diagnostic  data  flow 
associated  with  these  features  must  be  Incremental  and  continue  until  the  detail  prime 
system  Configuration  Item  designs  are  complete.  For  the  external  diagnostic  elements, 
such  as  automatic  test  equipment  and  the  associated  test  program  sets,  manual  test 
equipment,  portable  maintenance  aids,  technical  Information  (hard  copy  or  el*”  Ironic 
delivery),  training,  etc.,  the  diagnostic  data  flows  Into  the  LSA  process  up  to  the  point 
whore  the  firm  requirements  for  these  diagnostic  elements  can  be  established.  Once  firm 
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requirements  exist,  the  diagnostic  design  environment  must  facilitate  a  smooth  transfer  of 
data,  which  Is  sufficient  In  terms  of  detail  and  format  to  permit  fabrication  of  the  required 
external  diagnostic  capability. 

Table  5  Is  a  listing  of  the  major  military  standards  which  Influence  the  design  of 
the  diagnostic  capability.  Some  of  these  military  standards  are  programmatic  In  nature.  In 
that  they  establish  a  specific  program  and  describe  the  tasks  which  can  be  undertaken. 
The  remainder  of  the  standards  are  process  or  product-oriented.  As  can  be  seen,  these 
standards  Influence  various  aspects  in  the  design  of  the  diagnostic  capability,  starting 
from  establishing  diagnostic  requirements,  through  the  design  and  assessment  of  the 
diagnostic  capability.  Thera  Is  a  sequence  of  tasks  and  procedures  cited  In  these 
standards  which  can  be  applied  to  the  diagnostic  capability.  The  Interfaces  and 
relationships  between  these  various  activities  are  complex  and  cannot  be  easily 
diagrammed  to  promote  understanding.  Establishing  diagnostic  requirements  Is 
described  In  Requirement  #2,  and  the  assessment  Is  described  under  Requirement  #4. 
Thus  the  following  guidance  wilt  address  the  design  of  the  embedded  and  external 
diagnostic  capability. 


Design  Integration 

Figure  4  Is  a  simplified  diagram  of  the  Information  flow  In  the  design  of  the 
diagnostic  capability.  The  design  process  begins  with  a  maintenance  concept  and  design 
data,  such  as  specifications,  block  diagrams,  and  schematics.  Establishing  the  system's 
architecture  Is  the  next  step.  System's  architecture  has  a  major  Impact  on  the  design  of 
the  fielded  diagnostic  capability.  The  concept  of  fault  tolerance  supports  the  maintenance 
concept  by  promoting  graceful  degradation  of  the  system's  performance,  thereby  allowing 
the  maintenance  to  be  performed  at  the  user’s  convenience  rather  than  dictated  by  when 
faults  occur.  Design  for  testability  concepts  play  an  important  part  at  this  time. 
Partitioning  especially  is  closely  tied  to  fault  tolerance,  because  the  performance 
monitoring  capability  must  be  able  to  detect  failed  Items  In  order  that  the  capability  of  the 
system  Is  known,  that  necessary  switching  to  alternate  means  Is  facilitated,  and  that 
maintenance  actions  can  be  identified. 

The  Failure  Modes  and  Effects  Criticality  Analysis  (FMECA)  utilizes  the 
system's  architeoture  and  design  data  to  determine  the  modes,  causes  and  effects  of  Hern 
failures.  This  data  drives  the  maintenance  and  safety  requirements  which  In  turn  help  to 
establish  the  diagnostic  logic,  test  point  selection,  and  test  requirements.  From  this 
Information,  the  diagnostic  capability  Is  designed  and  fabricated,  including  the  testing, 
(built-in  and  external),  technical  information,  training,  and  personnel  capability.  Obviously 
this  entire  process  Is  Iterative  In  nature  -  a  factor  not  lndlqate«Lln  Figure  4. 
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TABLE  6.  MILITARY  8TANDARD8  APPUCABLB  TO  THE  DE8IQN  OF  THE  DIAQN08TIC  CAPABILITY 


MtL-STD-IttV  PfveaAirw  ter 
PMCCA 


MIL-STD-2077  Ftaqutremwita 
tor  TPS _ 

MIL-STD-471  MatrrMrHWPy 
OeworwtTitlorr 

MIL-8TD-7Bt  ReliMNy 


MIL-8TD-197*  CwiPaet 
TraNng  Prog. 
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nOURE  4.  DESIGN  INTEGRATION  OF  DIAGNOSTIC  CAPABIUTY 
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Th»  concttpt  of  vortical  tastabillty  was  introduced  years  ago.  In  essence,  this 
concept  addressed  the  compatibility  of  testing  among  all  levels  of  maintenance,  including 
factory  testing.  The  core  of  this  concept  Is  twofold.  The  first  is  the  establishment  of  a 
Cone  of  Tolerance  among  these  levels,  and  the  second  deals  with  the  compatibility  of 
environments  under  which  these  teste  are  performed. 

The  Cone  of  Tolerance  concept  is  depicted  In  Figure  5,  In  which  the  testing 
tolerances  are  widened  as  the  unit  Is  tested  closer  to  Its  operational  environment. 


The  compatibility  of  testing  environments  can  be  Implemented  best  through  the 
use  of  common  test  equipment  at  Intermediate,  Depot,  and  Factory  Levels.  This 
commonality  of  test  equipment  and  any  associated  test  programs  is  the  method  for 
Implementing  this  compatibility. 

The  concept  of  vertical  testability  Is  key  to  the  Integration  of  the  design  of  the 
diagnostic  capability.  Therefore  additional  guidance  on  vertical  test  methods  Is  contained 
In  Appendix  0.  This  appendix  also  Includes  guidance  on  documenting  the  results  of 
vertical  testability  analysis  to  assure  this  Information  will  be  integral  to  the  diagnostic 
design  process, 

Extension  of  this  vertical  testability  concept  Is  recommended  for  the  entire 
fielded  diagnostic  capability.  Figure  6  depicts  this  concept,  in  which  vertical  testing  Is 
shown  on  the  left  and  Is  joined  by  technical  information  and  personnel  and  training 
compatibility  requirements.  Not  only  Is  this  compatibility  required  vertically,  but  also 
horizontally.  All  elements  that  make  up  the  diagnostic  capability  must  be  compatible  at 
each  maintenance  level. 

This  concept  of  vertical  and  horizontal  compatibility  is  key  to  the  Integration  of 
diagnostic  capability.  The  entire  process  Is  driven  by  the  diagnostic  logic  which  effects 
the  requirements  for  all  of  the  diagnostic  elements.  This  diagnostic  logic  oan  be 
established  by  a  variety  of  means  including  the  use  of  maintenance  dependency  charts, 
fault  trees,  etc.  To  implement  this  concept,  a  series  of  matrices  similar  in  format  to  Figure 
6  can  be  prepared  at  various  system  hierarchy  levels  {e.g.,  system,  subsystem,  LRU, 
SRU).  These  matrices  should  be  tailored  to  the  unique  requirements  of  a  specific  weapon 
system  and  may  be  used  in  conjunction  with  other  required  data  deliverables  (e.g.,  test 
requirements  document). 
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naURI  6.  DMiqn  InMgnitlon  of  Diagnootio  Capability 
AUTOMATION  OP  THI DIAONOOTIC  DI8IQN  PNOCISS 

Automation  of  tha  dlagnoatlo  datign  pro  ;aa8  lo  ancouragad  to  provida  a  mora 
afficlant  and  affaotiva  daaign  prooaaa.  Tha  dl-''  jnottio  daaign  prooaaa  should  ba  an 
Intagral  part  of  prima  tystam  oomputar<aldad  anginaaring  and  daaign. 

Tha  addad  afflolanoy  and  affaotivanass  In  tha  usa  of  automation  Is  raflaotad  In  a 
numbar  of  ways.  Tha  affaot  of  changas  In  althar  tha  diagnostic  daslgn  or  tha  prima 
systam  daslgn  can  ba  raadlly  ascartalnad  a«  tha  daslgn  prograssas.  This  Itarativa 
prooaaa  than  can  giva  tha  dasignar  Information  on  whathar  or  not  tha  diagnostic 
spaoificatlon  raquiramants  will  ba  mat.  In  addition,  automation  parmits  tha  concurrent 
davalopmatU  and  evaluation  of  tha  entire  diagnostic  capability  along  with  tha  remainder  of 
tha  prime  systam. 
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Diagnostic  Design  Tools 

Diagnostic  design  tools  snhanes  the  effectiveness  and  efficiency  of  the 
process;  A  description  of  available  tools  and  processes  Is  available  In  Appendix  C. 
Appendix  C  Identifies  automated  tools  which  can  assist  the  designer  In  performing  three 
major  facets  of  the  design  process:  system  architecture  design.  Implementation  of  design 
rules  and  practices,  and  diagnostic  authoring. 

The  first  element  pertains  to  design  automation  tools  that  assist  the  designer  In 
synthesizing  a  prime  system  functional  capability,  as  well  as  providing  an  "environment" 
for  developing  a  diagnostic  capability  concurrently  with  the  prime  weapon  system 
development  process.  The  architectural  tools  not  only  provide  a  capability  tc  synthesize  a 
functional  capability,  but  also  assist  the  designer  in  understanding  systems  methods  of 
doing  design  work  (I.e.,  operatlonj.These  tools  generate  documentation  data  bases, 
which  are  either  explicitly  or  Implicitly  usable  in  the  testing,  technical  Information  and/or 
personnel  training  disciplines. 

The  second  element  pertains  to  automated  or  manual  tools  which  "capture" 
expert  knowledge  bases  in  dlagnostlc^related  matrices  for  uss  by  the  designer.  These 
knowledge  bases  may  range  from  highly  sophisticated  and  automated  expert  system 
software  to  unautomated,  rudimentary  checklists. 

The  final  element  pertains  to  tools  and/or  techniques  which  enable  the  designer 
to  "author”  (I.e.,  generate)  diagnostic  software  routines  and  procedures  utilizing  prime 
system  design  data  bases  or  heuristic  information  sources.  These  diagnostic  authoring 
tools  typically  take  the  form  of  either  expert  system  "knowledge  bridges,”  which  facilitate 
the  extraction  and/or  generation  of  diagnostic-related  procedures;  or  automatic  test 
generators/fault  simulators,  which  generate  digital  test  vectors  to  fault  detect/fauit  Isolate 
an  explicitly  defined  fault  universe  (i.e.,  stuck  "T/stuck  "0").  In  addition,  time-tested 
analog  and  mixed  mode  simulators  may  be  utilized  not  only  as  functional  design  tools,  but 
also  as  diagnostic  authoring  tools  In  deriving  and  analyzing  diagnostic  test  tolerances 
utilizing  worst  case  or  Monte  Carlo  analysis  techniques. 
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REQUIREMENT  #3.1 


CHECKLIST 


of  Has  a  concertad  effort  bean  made  to  oaeure  vertical 
and  horizontal  Integration  and  compatibility  of 
all  elemente  which  comprise  the  diognoatic  capability? 
Haa  thia  been  documented  for  review? 


C2f  Have  etepa  been  taken  to  utilize  automation  of  the 
diognoatic  deaign  proeeaa  to  enhance  deaign  efficiency 
ana  to  improve  the  effectiveneaa  of  the  fielded 
diognoatic  capability?  Hove  available  design  toola 
been  utilized? 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTIVITY 

zx  zx  zx  zs 

SYSTEM  SYS.  PREL  DETAIL 

ANALYSES  SPEC.  DESIGN  DESIGN 

DIAGNOSTIC 

ACTIVITIES 

DIAGNOSTIC  DESIGN 

DIAQNOSTIC  ACnVITY 

Dftslgn  of  th«  dlagnostlo  capability  and  tha  alamants  that  maka  up  this 
capability  ara  Initlatad  aarly  In  waapon  syttam  davalopmant.  It  bagins  soon  aftar  Initial 
analysas  and  allocation  ara  complatad  and  axtanda  at  laast  until  Full-Scala  Davalopmant 
haa  baan  complatad.  Daaign  critarla  and  guldanca  naad  to  ba  avallabla  for  uaa  as  tha 
dlagnostlo  capability  daaign  prograasas.  Obviously,  tha  bulk  of  this  design  guidance  Is 
utilized  by  tha  designer  of  tha  prime  system  and  Its  support  capability.  He  needs  to  ba 
totally  familiar  with  guidance  that  Is  available  and  be  able  to  apply  It  appropriately. 

PROCePURB 

Design  criteria  and  guidance  relating  to  tha  diagnostic  capability  and  individual 
dlagnostlo  alamants  ara  available  from  a  number  of  sources,  including  standards, 
handbooks,  and  guides.  Most  often,  this  guldanca  Is  not  a  contractual  requirement, 
except  whan  a  specific  military  standard  Is  Invoked.  However,  for  the  most  part,  the 
contractor  should  utilize  this  guidance  material  as  he  sees  fit,  as  long  as  diagnostic 
requirements  are  mat  and  Interfaces  are  controlled.  In  addition,  examples  which  depict 
the  Integration  of  the  various  diagnostic  elements  will  be  of  value  to  both  the  manager  and 
the  designer. 

Guidance  to  the  designer  consists  of  material  contained  In  this  section  and 
Identification  of  additional  guidance  where  published  material  Is  not  readily  available. 
Tools  to  assist  In  the  design  process  are  described  In  Appendix  C,  3.0. 
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GUIDANCE 

The  following  are  references  to  existing  design  criteria  and  guidance. 

General  Guldanee 

1 .  MIL<STD-454,  Standard  General  Requirements  for  Electronic  Equipment 

This  standard  covers  the  common  requirements  to  be  used  In  military 
specifications  for  electronic  equipment.  Reliability,  maintainability,  and 
human  engineering  requirements  are  included  In  this  standard.  However, 
for  these  types  of  engineering  disciplines,  the  guidance  stresses  that  this 
standard  does  not  establish  requirements  and  must  not  be  referenced  In 
contractual  documents.  These  three  requirement  examples  offer  direction 
on  what  should  be  considered  in  preparing  contractual  documents. 

2.  MIL-STD-416,  Design  Criteria  for  Teat  Provisions  for  Electronic  Systems  and 
Associated  Equipment 

This  standard  establishes  design  criteria  for  test  provisions  that  permit  the 
functional  and  static  parameters  of  electronic  systems  and  associated 
equipment  to  be  monitored,  evaluated,  or  Isolated.  The  standard.  In  Its 
present  form,  (Revision  D)  addresses  older  technologies  and  thus.  If 
referenced  In  contractual  documents,  must  be  tailored  to  address  only 
certain  provisione  In  this  standard. 

3.  The  RADC  Reliability  Engineers  Tool  Kit 

The  Tool  Kit  is  Intended  for  use  by  a  practicing  reliability  and  maintainability 
(R&M)  engineer.  Emphasis  Is  placed  on  his  role  In  the  various  R&M 
activities  of  an  electronic  systems  development  program.  The  Tool  Kit  Is  a 
compendium  of  useful  R&M  reference  information  to  be  used  In  everyday 
practice. 

4.  Study  of  the  Causes  of  Unnecessary  Removals  of  Avionics  Equipment 
(RADC-TR-e3-2) 

This  study  cites  and  verifies  the  causes  of  unnecessary  removals  of  suspect 
Items  from  avionics  equipment  and  contains  information  on  minimizing  this 
problem. 
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System  Architecture 

Appendix  E  contains  a  compendium  of  testability  and  diagnostic  design 
techniques,  which  provides  designers  various  approaches  and  techniques  for  achieving 
improved  testing  of  weapon  systems.  There  are  a  number  of  other  guides,  which  address 
the  architecture  of  the  system  design,  that  promote  Improvements  in  the  system's 
diagnostic  capability.  Included  are: 

1.  Architecture  Specification  for  PAVE  PILLAR  Avionics,  January  1987, 
SPA9Q099001A 

This  specification  addresses  the  advanced  avionlos  architecture  which  is 
specifically  targeted  for  advanced  tactical  fighters  and,  In  general,  for  all 
military  aircraft  applioatlons.  This  architecture  promotes  a  muohJmproved 
approach,  which  will  foster  an  Improved  diagnostio  capability.  An  example 
of  this  approach  la  contained  later  In  this  section. 

2.  Reliability.  Testability  Design  Considerations  for  Fault  Tolerant  Systems 
(RAOC-TR-84-57) 

Furnished  reliability  and  testability  evaluation  and  application  guidance  for 
fault'tolerant  designs. 

For  fault  tolerant  systems,  it  is  important  that  the  design's  Inherent  testability 
provisions  Include  the  ability  to  detect.  Identify,  recover,  and  If  necessary,  reconfigure  and 
report  equipment  malfunctions  to  operational  personnel.  In  addition,  because  fault 
tolerant  systems  often  aro  characterized  by  complex  non-serial  reliability  block  diagrams, 
a  multitude  of  back-ups  with  non-zero  switch  over  times,  and  imperfect  fault  detection, 
Isolation,  and  recovery.  It  Is  imperative  that  the  technical  manager  assure  that  effective 
testability  provisions  are  Incorporated  in  the  system  design  concept.  If  not,  the  design 
when  fielded  will  exhibit  long  troubleshooting  times,  high  false  alarm  rates,  and  low  levels 
of  system  readiness. 

Fault  tolerance  and  recovery  strategies  will  have  a  significant  Impact  on  the 
degree  to  which  testability  Is  designed  Into  the  system.  For  example,  when  Incorporating 
testablllty/dlagnostlc  capability  Into  the  design,  the  penalties  imposed  by  a  fault  tolerant 
system  design  which  employs  active  redundancy  and  voting  logic  may  be  less  than  those 
Imposed  by  a  design  employing  standby  redundancy.  With  active  redundancy,  the  prime 
system  hardware  and  software  are  more  readily  adaptable  to  perform  multiple  functions 
(Including  those  required  for  testability).  In  active  redundancy  systems  with  voting  logic, 
the  performance/statuo  monitoring  function  assures  the  operator  that  the  equipment  Is 
working  properly.  This  approach  also  simplifies  the  isolation  of  faults  since  the  failure  Is 
easily  Isolated  to  the  locked  out  branch,  by  the  voting  logic.  In  systems  employing 
standby  redundancy,  test  capability  and  diagnostic  functions  must  often  be  designed  Into 
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«aoh  redundant  or  substitute  functional  path  (both  on-line  and  off-line)  in  order  to 
determine  their  status. 

Although  the  addition  of  redundancy  Is  usually  effective  In  Improving  system 
reliability,  the  technical  manager  is  cautioned  that  the  reliability  Improvement  may  be 
highly  dependent  on  achievable  FD/FI  levels.  In  some  oases,  It  is  possible  for  Imperfect 
FD/FI  to  actually  cause  system  reliability  to  degrade  as  more  redundant  equipment  Is 
added.  In  general,  the  effect  that  varying  levels  of  FD/FI  have  on  system  reliability  can 
be  evaluated  by  parametric  analyses.  The  range  of  FD/FI  values  used  In  the  analyses 
should  be  based  on  past  experience  with  simitar  hardware/software  systems  and  adjusted 
by  evolutionary  trends  and  expectations  for  state-of-the-art  devices  and  designs. 

Test  Methodology  for  Fault  Tolerant  Systems  -  The  following  discusses  a 
number  of  desirable  design  considerations  for  fault  tolerant  system  testability. 

0  Comparison  Method  -  An  effective  method  for  testing  similar  systems  with 
similar  Inputs  and  outputs  is  to  compare  outputs  and  flag  any  gross 
disagreements.  A  means  to  determine  which  branch  Is  faulted  and  an  error 
log  entry  should  be  mandatory. 

0  Redundancy  Verification  •  Each  redundant  path  should  be  tested  Individually 
to  prevent  the  mashing  of  faults  In  redundant  items. 

o  Flexing  of  Spares  •  Periodically  activate  the  bullt-in-test  of  the  hot  spares, 
log  any  errors  found,  and  report  status  before  these  Items  are  needed  for 
system  operation.  This  will  prevent  a  faulty  unK  from  being  switched  In  when 
the  system  reconfigures. 

0  Voting  Scheme  Technique  -  A  typical  example  of  a  voting  scheme  technique 
is  to  compare  output  values  from  three  different  sources.  Confidence  is 
placed  in  that  value  where  at  least  two  of  the  three  sources  agree.  Errors 
found  should  be  logged,  and  the  source  of  the  erroneous  value  should  be 
recorded  and  corrected  at  an  appropriate  maintenance  Interval.  Since 
diagnostic  procedures  are  generally  designed  to  locate  a  single  fault, 
potential  exists  for  the  occurrence  of  multiple  faults  (e.g.,  a  stuck-at-1  In 
multiple  locations)  than  can  go  undetected.  It  may  be  necessary  to  add 
logic  or  test  circuitry  to  ensure  that  each  state,  and  each  state  transition, 
occurs  correctly. 

0  Error  Correction  •  Detection  of  degraded  performance  in  states  preceding  an 
error  correcting  function  Is  difficult  since  the  error  correcting  function  makes 
its  preceding  degraded  state  appear  healthy.  The  error  correcting  functions 
should  keep  count  of  the  number  of  times  a  correcting  function  had  to  be 
made  and  a  record  made  In  an  error  log.  When  a  predetermined  threshold 
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count  Is  exceeded,  a  test  signal  may  be  Injected  to  determine  If  the  Input 
stage  Is  unacceptably  degraded. 

0  Multiple  Redundancy  •  In  redundant  systems,  which  are  allowed  to  degrade 
gracefully  through  failures  of  redundant  elements,  a  test  should  be 
established  to  verify  that  minimum  acceptable  system  performance  and 
redundancy  levels  are  available  at  the  start  of  a  mission. 

o  Caution  Indications  -  Fault  tolerance  can  be  applied  to  a  variety  of  system 
types  (l.e.,  electrical,  mechanical,  hydraulic,  environmental,  etc.). 
Regardless  of  the  system  type,  It  Is  customary  to  Include  a  cautionary 
Indication  whenever  a  back*up  system  is  called  Into  senrice,  especially  for 
safety  critical  functions. 

Fault  Detection  Latency  Times  •  One  of  the  most  rigid  demands  Imposed  upon  the 
testability  design  of  fault  tolerant  systems  Is  the  quick  response  time  necessary  to 
reconfigure.  Hence,  the  testability  design  process  must  take  into  account  both  spatial  and 
temporal  considerations  for  fault  detection.  The  failure  detection  approach  selection  must 
be  based  upon  the  requirement  for  maximum  acceptable  failure  latency.  Continuous 
failure  detection  techniques  should  be  used  to  monitor  those  functions  that  are  mission 
critical  and/or  affect  safety  and  where  protection  must  be  provided  against  the 
propagation  of  errors  through  the  system.  Periodic  testing  may  be  used  for  monitoring 
those  functions  which  provide  backup/standby  capabilities  or  are  not  mission  critical. 
Operator  Initiated  testing  Is  typically  used  for  monitoring  those  functions  which  require 
operator  Interaction,  sensor  simulation,  etc.,  or  which  are  not  easy,  safe,  or  cost-effective 
to  Initiate  automatically.  The  maximum  permitted  latency  for  failure  detection  determines 
the  frequency  at  which  diagnostic  procedures  should  be  run  and  must  take  into  account 
function  criticality,  failure  rate,  possible  wear  out  factors,  and  the  overall  maintenance 
concept. 

Testability 

There  are  a  number  of  guidance  documents  which  address  testability  Issues. 
Some  of  these  are  listed  below.  These  deal  with  the  design  techniques  of  controllability, 
observability,  and  partitioning.  Controllability  is  a  design  attribute  which  describes  the 
extent  to  which  signals  of  Interest  may  be  controlled  by  the  test  process.  It  relates  to 
difficulty  of  test  generation,  length  of  teat  sequence,  and  diagnostic  resolution. 
Observability  la  another  design  attribute  which  describes  the  extent  to  which  signals  of 
Interest  may  bo  observed  by  the  test  process.  The  emphasis  Is  upon  selection  of  the 
most  appropriate  test  points.  Partitioning  oeals  with  both  the  physical  hardv/are  and  the 
functional  partitioning  of  the  circuitry.  Test  times  and  test  generation  costs  escalate 
rapidly  as  partitioning  size  increases. 

1 .  RADC  Testability  Notebook,  Final  Technical  Report,  June  1982 
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This  notsbook  presants  a  consolidation  of  Information  relating  to  testability 
design  teohniques,  procedures,  cost  trade-off  tools,  and  the  relationship  of 
testability  to  other  design  disciplines  and  requirements.  Specific  examples 
of  good  testability  design  are  contained  In  this  document. 

2.  MIL-STD’2165,  Testability  Program  for  Electronic  Systems  and  Equipments 

Appendix  B  of  MIL-STO-2ie5  cites  a  series  of  factors  which  affect  the 
Inherent  testability  of  a  weapon  system.  This  Information  oan  be  used  either 
as  design  guidance  or,  If  weighted  and  scored,  can  actually  provide  a  Figure 
of  Merit  for  a  speoHIo  system/unit. 

3.  Testability  Analysis  Handbook  (Draft) 

At  the  time  of  printing  the  Contractor  Program  Managers  Guide,  the 
Testability  Analysis  Handbook  was  in  draft  form.  Publishing  Is  scheduled 
during  FY80.  The  Preparing  AotivHy  Is  the  Naval  Sea  Systems  Command, 
CEL-OST.  This  handbook  provides  a  systematic  methodology  for 
Implementing  testability  analysis  and  design  requirements,  which  are 
prescribed  In  MIL*STD-2ie5,  Tasks  201, 202,  and  203. 

4.  Predictions  of  Organizational  Level  Testability  Attributes  (RADC>TR*87>55) 

This  report  documents  a  methodology  for  predicting  fraction  of  faults 
detected,  fraction  of  faults  Isolated,  and  fraction  of  false  alarms  utilizing  field 
measured  data. 


Built-In  Teat 


1.  Built-In  Test  Design  Quide-Joint  AMC/CNO/AFLC/AFSC  Commanders, 
April  1987 

This  Joint  Service  BIT  Design  Guide  provides  detailed  guidelines  on  the 
implementation  of  BIT,  Including  BIT  design  techniques  at  all  levels  within 
the  weapon  system. 

2.  Smart  BIT  (RADC-TR-85-1 48) 

Application  of  Artificial  Intelligence  techniques  In  the  design  of  BIT,  to 
minimize  false  alamns,  retest  OKs  and  non-required  maintenance. 

3.  Sensor  Handbook  for  Test,  Monitoring,  Diagnostic,  and  Control  System 
Applications  to  Military  Vehicles  and  Machinery,  National  Bureau  of 
Standards 
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This  handbook  Is  Intendad  as  a  guide  for  those  who  design,  specify,  use, 
and  test  weapon  systems  containing  monitoring  sensors.  The  nandbooK 
addresses  measures  and  principles  of  measurement,  data  acquisition, 
sensor  calibration  and  testing,  environmental  considerations,  stability, 
durability,  reliability,  and  error  assessment  for  various  types  of  sensors. 

4.  Analysis  of  Built-In  Test  (BIT)  False  Alarm  Conditions  (RADC-TR-81-220) 

This  study  analyzes  the  root  causes  of  the  false  alarm  problem  and  provides 
design  guidelines  for  avoiding  BIT  false  alarms. 

5.  Design  Quldellr.ae  and  Optimization  Procedures  for  Test  Subsystem  Design 
(RADC-TR-80-111) 

This  study  provides  guidelines  and  procedures  to  optimize  the  design  of 
bullt-ln  test. 

6.  BIT  Verification  Techniques  (RADC-TR-86-241) 

This  report  covers  practical  verification  techniques  for  formal  and  field 
demonstration  of  BIT  effectiveness. 

The  problem  of  BulK-ln-Test  False  Alarms  and  Cannot  Duplicates  have  plagued 
design  for  many  years.  These  problems  must  receive  the  full  attention  of  system 
designers,  Future  generations  of  BIT  must  Include  more  emphasis  on  Interpretation  of 
detected  system  anomalies  and  better  accounting  for  real  world  system  operating 
conditions  such  as  fielded  system  performance,  environmental  and  operational  faotora. 

In  order  for  the  BIT  to  reach,  and  remain  at,  Its  full  potential  In  the  field.  It  must 
be  designed  with  sufficient  flsKlblllty,  Including  the  ability  to  easily  adjust  test  limits  and  to 
change  BIT  software  without  affecting  tactical  software. 

According  to  the  above  referenced  document  "Analysis  of  Bullt-ln-Test  (BIT) 
False  Alarm  Conditions”,  a  common  cause  of  false  alarms  are  sudden  environmental 
stresses  such  as  momentary  high  temperatures,  or  a  high  "Q*  turn.  The  Rome  Air 
Development  Center,  at  the  time  of  this  printing,  Is  developing  a  Time  Stress 
Measurement  Device  (TSMD)  chip  which  will  monitor  and  categorize  (In  compacted  form) 
data  relative  to  the  temperature,  axial  vibration  and  shock,  and  power  quality  that  the 
equipment  sees  over  time.  A  larger  module  has  already  been  developed  and  flight  tested 
which  can  monitor  such  characteristics.  In  the  future,  BIT  Indications  can  be  correlated 
with  TSMD  data  to  help  eliminate  the  occurrence  of  false  alarms  and  CNDs.  The 
Integration  of  BIT  Indications,  TSMD  data,  and  smart  (artificial  Intelligence)  processing 
may  also  potentially  yield  even  greater  accuracy  for  onboard  diagnostics. 
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Autonwtle  TMt  Equipment  (ATE) 

1 .  Modular  Automatic  Taat  Equipment  (MATE)  Handbook 

Although  Air  Force-oriented,  this  handbook  describe  procedures  and 
techniques  for  acquiring  automatic  test  equipment. 

2.  MIL-STD-2077,  General  Requirements.  Test  Program  Sets 

This  standard  covers  the  acquisition  of  test  program  sets  for  use  with  ATE. 
Design  criteria  Is  Included,  which  addresses  many  detail  requirements  for 
TPSs. 

Human  Engineering 

1,  MIL-STD-1472.  Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

This  standard  covers  general  human  engineering  design  criteria  which  can 
be  applied  to  any  weapon  system. 

Technical  Information 

There  are  a  variety  of  standards  which  address  the  preparation  of  technical 
publications.  Most  of  these  documents  are  directed  at  a  specific  military  service.  All 
address  the  delivery  of  paper-type  documentation.  There  Is  no  firm  guidance  relating  to 
other,  perhaps  more.  Innovative  means  for  generating  and  delivering  technical 
Information.  In  the  past,  many  technical  publications  have  been  cited  to  have 
deficiencies.  These  deficiencies  can  best  be  described  In  the  DoD  Audit  Report  No.  B7- 
1 1S,  April  3,  1987,  'Summary  Report  on  the  Defense-Wide  Audit  on  Acquisition  of 
Technical  Manuals  and  Related  Data  From  Contractors.” 

Means  should  be  sought  for  generating  and  delivering  this  technical  Information 
In  a  less  costly  manner,  without  compromising  Its  quality.  There  are  a  number  of  tools 
available,  or  under  development,  which  can  assist  the  designer  of  this  technical 
Information  In  authoring  the  text,  when  electronic  delivery  of  technical  information  is 
contemplated.  Some  guidelines  and  standards  for  automatic  generation  of  technical 
information  and  Its  delivery  eleotronically  can  be  obtained  from  the  Human  Resources 
Laboratory  at  Wright-Patterson  Air  Force  Base.  This  guidance  Information  has  been 
developed  under  the  Integrated  Maintenance  Information  System  (IMIS)  Program. 

Innovative  Ideas  for  displaying  this  technical  Information  are  encouraged,  as 
stipulated  In  Task  303,  MIL-STD-1 388-1.  Care  should  be  taken  to  provide  for  quick 
access  to  the  required  data.  For  electronic  delivery  of  this  data,  formats  may  vary 
substantially  from  paper-based  technical  manuals.  Previously  specified  access  times  and 
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Information  modification  timaa  should  Influanoe  the  typa  of  generation  and  delivery 
methods.  DoD'Instructlon  4151.9  requires  the  services  to  plan  and  schedule  the 
acquisition  of  technical  manuals  (technical  Information)  to  ensure  their  availability  In  final 
form  before,  or  concurrently  with,  delivery  of  the  system  to  the  field.  During  design,  final 
plana  should  be  developed,  along  with  the  support  equipment  which  Is  furnished. 

Maintenance  Aids 

There  is  a  need  to  present  technical  information  and  troubleshooting  advice  to 
the  technician  on  location  and  readily  available  for  his  use.  The  maintenance  aid, 
sometimes  called  a  Job  performance  aid,  presents  Information  generated  by  experts  to 
assist  the  leas-expericnced  technician. 

The  maintenance  aid  Is  a  device,  publication,  or  guide  used  on  the  job  to 
facilitate  performance  of  maintenance.  It  delivers: 

0  Historical  information  on  what  fault  was  found  when  similar  symptoms  were 
experienced 

0  Troubleshooting  logic  to  assist  In  finding  the  fauK 

0  Procedural  Information  which  assists  the  technician  in  finding  and  correcting 
a  failure. 

Normally,  a  maintenance  aid  is  used  in  conjunction  with  a  testing  capability. 
Maintenance  aids  could  be  paper-based  or  employ  electronic  delivery  systems. 

Electronic  delivery  of  this  type  of  Information  opens  the  door  to  solving  some  of 
the  problems  associated  with  paper  maintenance  aids.  Two  attributes  of  electronic 
delivery  systems  are: 

o  Information  can  be  available  to  the  technician  in  a  matter  of  seconds  by 
carefully  constructed  menus,  in  lieu  of  the  technician  having  to  page 
through  a  paper  document. 

o  The  collection  of  historical  data  and  the  subsequent  modification  to  the 
software  programs  which  deliver  this  technical  Information  can  be  updated 
In  a  matter  of  seconds.  Instead  of  a  matter  of  months. 

This  latter  attribute  lends  Itself  to  the  introduction  of  expert  systems,  which  often 
employ  artificial  Intelligence  technology.  The  expert  system  has  the  capability  of 
combining  various  pieces  of  Information  to  lead  the  technician  to  a  logical  decision  on 
what  Is  faulty  and  how  it  can  be  repaired. 
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Anothtr  Important  aspect  of  the  maintenance  aid  is  its  ability  to  train  technicians 
on  the  Job.  Training  programs  must  be  closely  associated  with  the  design  and 
development  of  a  maintenance  aid. 

Over  the  past  20  years,  many  maintenance  aids  have  been  designed, 
developed,  and  tested.  These  tests,  for  the  most  part,  have  proven  successful.  However, 
the  transition  of  these  maintenance  aids  Into  the  field  has  not  been  accomplished  to  any 
great  extent.  One  of  the  reasons  Is  that  specifications,  standards,  and  guidance 
Information  on  how  to  Invoke  this  requirement  are  lacking. 

A  few  Important  facts  should  be  remembered  when  applying  maintenance  aids 
and  expert  systems. 

0  The  design  of  the  maintenance  aids  must  be  done  with  the  user  in  mind. 
Once  a  working  model  of  the  equipment  Is  available,  there  should  be  a 
dynamic  Interchange  of  Information  between  the  maintenance  technician 
and  the  design  engineer  to  ensure  an  effective  and  efficient  man-machine 
Interface  is  attained. 

0  User  acceptance  and  adoption  of  maintenance  aids  will  be  facilitated  In 
cases  where  potential  users  are  given  a  trial  period  In  which  to  become 
familiar  with  these  devices  prior  to  their  formal  Implementation. 

0  A  system  must  be  devised  to  assure  timely  updating  of  Information  to 
correct  errors  and  to  add  newly  acquired  Information.  Without  such  a 
system,  the  maintenance  aid  will  quite  rapidly  become  obsolete, 


Manpower  and  Training 

After  personnel  and  training  requirements/allocations  have  been  made,  the 
training  curriculum  needs  to  be  established  concurrently  with  the  system  detail  design. 
This  Includes  the  formal  schooling  curriculum,  as  well  as  on-the-job  training.  One  of  the 
alternatives  available.  If  electronic  delivery  of  technical  Information  is  employed.  Is 
combining  training  aids  with  the  delivered  technical  Information.  These  two  types  of 
Information  (aiding  and  training)  are  somewhat  similar  in  nature  and,  at  times, 
indistinguishable.  The  training  curriculum  should  be  aimed  at  the  user(s)  and  accessed  In 
a  manner  which  can  be  utilized  by  a  variety  of  users. 

Those  training  devices  can  be  freestanding  or  embedded  In  the  prime  system. 
They  can  serve  as  Just  maintenance  training  devices  or  they  can  be  Incorporated  with 
operational  training.  Separate  and  distinct  training  devices  (maintenance  trainers)  may  be 
required  to  be  developed  for  the  formal  schooling. 
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PROGNOSTICS 

Although  raroly  conaidarad  in  alactronlo  syatam  daaign,  prognoatlos  (IncIplant 
failura  datactlon)  tachniquai  may  hava  a  significant  Impact  In  Improving  tha  oparatlonal 
raadinaas  and  mission  success  rata  of  future  systems.  Having  tha  ability  to  test  an 
equipment  to  sea  If  any  of  Its'  critical  components  are  soon  to  fail  could  radically  change 
tha  repair  philosophy  for  a  ayatam.  An  RAOC  study  entitled  "Marginal  ChaoKIng" 
Indicated  that  often  prognostics  tachnlquaa  must  be  developed  on  an  Item  by  Item  basis. 
This  being  the  case,  it  makea  sense  to  concentrate  first  on  developing  techniques  for 
detecting  Incipient  failure  of  high  failure  rate  critical  components.  The  "Marginal 
Checking"  study  has  identified  potential  prognostics  techniques  which  are  appropriate  to 
cables,  power  supply  bridge  rectifiers  and  CMOS  circuitry. 

Integration  of  Diagnostic  Elements 


There  are  a  variety  of  ways  in  which  diagnostic  elements  can  be  Integrated  to 
produce  a  more  effective  and  efficient  diagnostic  capability.  Expert  system  technology 
can  be  Incorporated  In  either  ATE  or  BIT  to  eupplement  the  baalc  testing  capability.  Fault* 
tolerant  design  and  teatabllHy  design  can  be  Introduced  Into  prime  system  architecture  to 
promote  ease  of  testing,  along  with  graceful  degradation.  Maintenance  elding  and 
maintenance  training  can  be  combined  to  provide  on-the-job  maintenance  and  training 
Information,  utilizing  a  single  portable  device  or  embedded  Into  the  prime  system.  Two 
examples  of  this  type  of  Integration  follow. 

ADVANCBD  AVIONICS  ARCHITBCTURB  gMBQDIBP  IN  THl-gAYI 

ElLLSfi 

Advanced  Modular  Avionlee  Dlagneetie  Requirementa 

Mission  availability  and  probability  of  mission  success  expectations  for 
advanced  modular  avionic  architectures  such  as  PAVE  PILLAR  are  totally  dependent 
upon  the  embedded  diagnostic  capability  that  is  Implemented  as  an  Integral  part  of  the 
design.  The  Implication  of  this  statement  represents  a  significant  departure  from  the 
traditional  relationship  that  has  existed  between  the  circuit  design  and  BIT/testabliity 
disciplines.  An  overview  of  the  PAVE  PILLAR  modular  avionics  architecture  with  Its 
Integral  diagnostic  features  Is  provided  In  the  paragraphs  that  follow  to  facilitate  an 
understanding  of  the  new  relationship  that  must  be  developed. 
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PAVE  PILLAR  Ov«rvl»w: 

PAVE  PILLAR  Is  a  highly  modular  flaxibla  avionlo  system  arohitscture  which 
employs  a  common  modulo  sot  to  oxploit  the  commonality  In  alr-to-air  and  alr-to*ground 
missions,  The  major  functional  partitions  of  the  avionics  suite  are;  Digital  Signal 
Processing,  Mission  Processing,  Vehicle  Management  Processing,  and  Avionics  System 
Control.  Figure  7  depicts  the  enclosing  boundaries  (l•••.  Digital  Signal  Processing, 
Mission  Processing,  and  Vehicle  Management  Processing)  for  resource  sharing,  sparing, 
and  substitutions.  The  unique  characteristics  of  the  functions  within  each  of  these 
boundaries  preclude  the  utilization  of  resources  across  boundaries  for  the  purpose  of 
recovery  or  reconiigur  tion.  Aa  a  consequence  of  this  partitioning,  the  diagnostic  process 
takes  place  within  ;ha.<ss  boundaries  and  the  associated  results  are  communicated  across 
the  boundaries  to  provide  the  pilot  with  the  required  system  status.  The  system 
archKecture  which  supports  the  diagnostic  process  is  described  In  the  paragraphs  below. 

Dlagitostlo  Strategy: 

The  PAVE  PILLAR  advanced  system  architecture  employs  a  hierarchical 
approach  that  spans  system  elements  from  the  individual  chips  to  the  entire  system. 
Essential  features  of  this  hierarchical  diagnostic  architecture  are  shown  In  Figure  6.  The 
Incorporation  of  a  test  control  function  at  each  level  of  fault  detection  (i.e.,  chip,  LRM, 
subsystem,  and  system)  can  facilitate  both  fault  screening  and  test  augmentation 
functions.  The  Inherent  flexibility  provided  by  this  architecture  provides  the  system 
designer  the  ability  to  meet  weapon  system  specific  diagnostic  requirements  with  a  suite 
of  standard  modules. 

It  Is  essential  that  both  the  system  and  detail  designer  recognize  the  Importance 
of  Implementing  such  a  hierarchical  diagnostic  structure.  A  suite  of  standard  line 
replaceable  module  (LRMs)  will  have  Individual  fault  detection,  fault  Isolation  and  false 
alarm  rate  specifications  that  are  not  necessarily  adequate  to  meet  the  system-level 
requirements  imposed  without  fault  screening  and  test  augmentation.  Advanced  BIT 
concepts,  which  have  been  Introduced  through  the  "Smart  BIT*  project,  are  both 
compatible  and  dependent  upon  the  availability  of  a  hierarchical  diagnostic  architecture. 
A  representative  diagnostic  Implementation  Is  provided  in  Figure  9, 

LRM  Bus  Structure: 

The  bus  structure  associated  with  the  diagnostic  system  Implementation,  shown 
In  Rgure  9,  Is  dependent  upon  local  maintenance  and  data  buses,  as  well  as  system  level 
multiplex  data  communications.  At  the  chip  and  module  level,  the  primary  diagnostic 
control  Is  provided  over  the  VHSIC  Phase  2  defined  TM  •  Bus. 
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FIGURE  7.  -  COMMON  ARCHITECTURE 
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Communication  of  diagnostic  Information  between  subsystems  within  the  major 
PAVE  PILLAR  partitions  (i.e.,  Signal  Processing,  Mission  Processing,  and  Vehicle 
Management  Processing)  takes  place  over  the  respective  partition  Multiplex  Bus.  This 
configuration  permits  the  use  of  a  separate  diagnostic/maintenance  processor,  or  the 
Incorporation  of  these  functions  v/lthin  the  mission  processing  function,  This  diagnostic 
system  Implementation  is  also  compatible  with  the  requirements  for  the  System  Status 
function,  as  currently  defined  under  the  Pilots  Associate  Program.  (The  Pilots  Associate 
Program  is  sponsored  by  the  Defense  Advanced  Research  Projects  Agency  under 
Program  Element  Number  62301 E.  The  performing  activity  Is  the  Wright  R&D  Center 
(WRDC). 

Diagnostic  Applications,  Summary  and  Conclusions: 

The  diagnostic  architecture  described  above  Incorporates  all  the  necessary 
functions  to  support  the  following  operational  and  diagnostic/testability  objectives; 

Fault  Detection 

Fault  Screening 

Fault  isolation  (Controllability,  ObservaJaility) 

Fault  Recovery  (Redundancy,  Reconfiguration,  or 
Qraceful  Degradation) 

System  Status  Indication 

Maintenance  Data  Recording 

Repair  Verifloatlon 

Off'Board  Maintenance  Interface  (IMIS) 

In  additional  to  the  complete  range  of  functions  Identified,  the  hierarchical 
diagnostic  architecture  offers  sufficient  flexibility  for  the  system  designer  to  aohievs  the 
weapon  system  supportablllty  required.  The  layered  access  to  the  diagnostic  capability 
within  the  system  Is  essential  for  the  application  of  arllflolal  Intelligence  based  BIT 
techniques  being  developed  under  programs  such  as;  Smart  BIT,  Flight  Control 
Maintenance  Diagnostic  System,  Pilots  Associate,  etc.  (These  latter  two  programs  are 
being  performed  by  the  Wright  R&D  Center  (WRDC),  WPAF6,  Ohio.) 

B-1B  EXAMPLE  OF  DIAGNOSTIC  INTEQRAT10N 

The  B<1B  Bomber  provides  an  example  of  many  different  facets  of 
diagnostics  deliberately  combined  to  provide  a  total  Integrated  diagnostics 
capability.  The  diagnostic  elements  Include  conventional  and  artificial  Intelligence 
diagnostic  techniques,  real-time  In-flight  performance  monitoring  and  ground 
readiness  testing,  system  performance  monitoring  for  aircrew  Information  and  LRU 
fault  Isolation  for  maintenance  personnel,  detailed  embedded  data  acquisition 
equipment  and  ground  processing,  standard  Inspection  and  other  scheduled 
maintenance  tasks  (primarily  In  mechanical  areas),  and  status  Information 
developed  by  the  defensive  and  offensive  avionics. 
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As  shown  In  Figure  10,  the  core  of  the  B-IB  diagnostics  Is  an  on-board 
Central  Integrated  Test  System  (CITS).  The  general  philosophy  of  CITS  Is  to 
monitor  and  record  activity  on  the  aircraft  equipment  buses  as  well  as  performance 
status  Information  generated  by  the  defensive  and  offensive  avionics  system. 
Signal  levels  are  compared  to  standards  by  the  CITS  computer.  In  the  event  of  a 
failure,  a  CITS  Maintenance  Code  (CMC)  Is  generated  identifying  the  faulty  LRU. 
Both  the  CMC  and  measured  signal  levels  are  recorded  for  later  analysis  by  a 
ground  processor  located  in  the  Intermediate  shop. 

Embedded  equipment  which  makes  up  CITS  Include  four  data  acquisition 
units,  a  CITS  computer,  an  airborne  printer,  a  CITS  control  and  display  panel,  and 
the  CITS  maintenance  recorder. 

Associated  ground  equipment  Is  the  CITS  Ground  Processor.  It  Is  used 
for  retrieving  and  Interpreting  the  data  recorded  during  each  flight.  The  artificial 
Intelligence  portion  of  the  diagnostics  (CITS  Expert  Parameter  System  or  CEPS)  Is 
also  resident  In  a  separate  ground  computer.  The  CITS  Ground  Processor  Is  used 
to  evaluate  the  maintenance  codes  recorded  In  flight  and  Issue  work  orders  directing 
the  removal  of  the  faulty  LRU.  CEPS  is  used  when  the  CMC  does  not  Isolate  the 
fault  to  single  LRU.  CEPS  utilizes  past  history,  expert  diagnostic  approaches,  and 
monitored  environmental  data  at  the  time  of  the  failure  to  further  break  the  CITS 
ambiguity  groups  for  Isolation  to  the  single  failed  LRU. 

Technical  Orders  (TOs)  and  crew  training  still  play  an  Important  part  In  the 
overall  diagnostics.  Ground  readiness  tests  are  manually  Initiated  following  an  LRU 
replacement.  These  tests  are  to  assure  proper  system  operation.  They  are 
performed  per  Instructions  In  the  TOs  using  the  applicable  tests  of  CITS.  In  addition 
there  are  limited  physical  Inspections  directed  by  the  TOs  covering  the  traditional  but 
still  effective  monitoring  of  wear  and  fluid  contamination. 

The  design  process  of  Integrating  all  of  the  above  centered  around  three 
established  disciplines.  They  are  1)  a  structured  systems  engineering  approach,  2) 
a  Failure  Mode,  Effects,  and  Criticality  Analysis  (FMECA),  and  3)  Logistic  Support 
Analysis  and  Support  Equipment  Recommendation  Data  development. 

CITS  design  manuals  governed  the  systems  engineering  process.  These 
manuals  were  created  following  MIL-Standard  software  development  specifications 
and  associated  reviews.  A  basic  document  called  CITS  Autoflow  was  created  for 
each  system/subsystem  which  delineated  the  tests  to  be  made  for  fault  detection 
and  Isolation.  The  Autoflow  Identifies  which  Inputs  and  outputs  from  each  box  are  to 
be  checked  to  assure  that  the  problem  Is  within  the  box  and  not  caused  externally. 
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FIGURE  10.  B-1B  MAINTENANCE  CONCEPT 
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A  detailed  Failure  Modes,  Effects  and  Criticality  Analysis  (FMECA) 
provided  the  Initial  basis  for  selecting  CITS  teats.  This  was  augmented  by  a 
structured  LSA  which  Identified  all  diagnostic  tasks  required  to  be  accomplished. 
Part  I  Support  Equipment  Recommendation  Data  (SERD)  was  created  documenting 
the  need  for  all  applicable  support  equipment.  CITS  personnel  then  evaluated  each 
SERD  and  where  possible  made  sure  that  the  requirement  was  met  by  CITS. 
Where  applicable,  other  visual  Inspections,  etc.,  were  also  considered.  All  SERD 
requirements  were  eventually  satisfied  without  the  use  of  a  significant  amount  of 
ground  support  equipment. 
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ANALYSIS  AND  ASSESSMENT  OP  THE  PERFORMANCE  OP  THE  DIAGNOSTIC 
CAPABILITY 

TESTABILITY/ 

OVERYliW  DIAGNOSTICS 


Throughout  tho  design  of  the  weapon  system's 
diagnostic  capability,  It  Is  essential  to  analyze, 
assess  and  demonstrate  Ita  pertormancev  Such 
assessments  are  an  integral  part  of  logistics, 
reliability,  maintainability,  testability,  human 
engineering,  software  and  safety  programs.  The 
ability  to  properly  conduct  these  analyses, 
assessments,  and  demonstrations  la  hampered  by 
the  lack  of  available  techniques  and  toots  to  help, 
and  the  Incompatibility  of  the  available  tools  and 
techniques  to  function  together.  Thus  both  the 
program  manager  and  the  designer  must  have 
sufficient  knowledge  to  understand  the  processes 
utilized  and  Integrate  these  processes  and  tools  to 
do  the  best  possible  Job. 


PROGRAMMATIcl 

REQUIREMENT$n 


■— H  REVIEWS  I 
— I  EVALUATION  ) 


I— ^  MATURATION  ) 


IMPORTANT  CON8IDERATION8  TO  BE  ADDRESSED 


4.1  Analyele  and  aeseaement  of  the  diagnostic  capability  should  be 
performed  for  the  entire  diagnostic  capability,  as  well  as  for  each 
diagnoatio  element 

4.2  Maintainability  demonatratlons  ahould  be  designed  to  verify  that 
diagnoatio  requirementa  have  been  met 
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WEAPON 

SYSTEM 

AGO.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

PSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTIVITIES 

AAA 

SYSTEM  PREL  DETAIL 

SPEC.  DESIGN  DESIGN 

DIAGNOSTIC 

ACTIVITIES 

A  A  A 

IN-PROCESS  ASSESSMENTS 

DIAGNOSTIC  ACTIVITY 

OurlriQ  D«m/Val  and  PSD,  It  Is  Important  to  aisoss  whothar  tha 
tastablllty/dlagnostio  raquiramanti  ara  baing  achlavad.  This  activity  aneompassas  all 
prallmlnary  and  fulLsoala  anginaaring  activltlas  partalning  to  both  tha  ambaddad  and 
axtamal  diagnostic  oapablitty. 

PROCEDURE 

In-prooasa  tastablllty/dlagnostic  analyses  can  ba  conducted  at  most  any  time 
within  Dam/Val  and  PSD.  These  In-prooasa  analyses  ara  typically  reviewed  by  tha 
government  at  Preliminary  Design  Reviews  and  Critical  Design  Reviews.  These  analyses 
are,  for  the  most  part,  Implemented  per  MIL<STO*2165  (Task  202,  Prallmlnary  Design, 
and  Task  203,  Detail  Design).  Normally,  these  analyses  will  be  tha  responsibility  of  the 
design  or  teat  engineer. 
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CiyiBANQB 

Basically,  thtra  art  two  types  of  ln*procoss  analyses.  The  first  deals  with  the 
Inherent  testability  of  the  hardware  design  and  is  Independent  of  test  stimuli  and  response 
data.  The  second  type  deals  with  the  effectiveness  of  the  diagnostic  capability  which 
deals  with  measures  that  Include  consideration  of  hardware  design,  embedded 
diagnostics,  and  external  diagnostics.  Diagnostic  effectiveness  measures  Include,  but  are 
not  limited  to,  fault  coverage,  fault  resolution,  fault  detection  time,  fault  isolation  time,  and 
false  alarm  rate. 

There  are  a  number  of  techniques  and  tools  available,  both  automatic  and 
manual,  which  can  be  used  to  assist  in  these  analyses.  A  thorough  description  of 
available  techniques  la  contained  In  the  Testability  Analysis  Handbook,  which  la 
referenced  under  Requirement  #3.2.  A  description  of  available  tools  to  assist  in  these 
analyses  Is  contained  In  Appendix  C. 

INHERENT  TESTABILITY 

The  first  analysis  deals  with  Inherent  testability.  Inherent  testability  assessment 
Is  an  evaluation  of  how  well  a  design  supports  the  testing  prooeaa.  whether  built-in  test  or 
off-line  test.  The  evaluation  is  preformed  on  the  preliminary  design  and  la  performed 
before  any  test  design  Is  performed,  it  Is.  therefore,  based  solely  upon  the  hardware 
design  features,  such  as  physical  and  electrloai  partitioning,  controllability,  observability, 
and  test  point  placement,  etc.  The  key  to  performing  an  Inherent  testability  assessment  Is 
the  Identifloatlon  of  features  which  support  or  inhibit  the  diagnostic  process  early,  at  a 
point  In  time  when  the  design  oan  be  changed  relatively  easily.  The  concept  and  the 
Implementation  of  an  Inherent  testability  assessment  oan  have  great  Impact  on  overall 
system  supportabillty. 

In  general,  three  generic  groups  of  Inherent  testability  predictive  techniques  are 
available,  each  with  Its  unique  advantages  and  disadvantages.  Checklists  are  low  cost, 
manual,  and  somewhat  simpliatio.  Logic  models  utilize  the  actual  circuit  topology  but 
often  regard  everything  as  a  block,  with  inputs  and  outputs.  The  more  detailed 
algorithmic  approaches,  such  as  Sandia  Controllabllity/Observablllty  Analysis  Program 
(SCOAP),  require  libraries  of  the  devices  that  most  nearly  simulate  actual  circuit  devieas. 

Checklist  approaches  to  Inherent  testability  assessment  have  some  very  good 
characteristics.  Checklists  are  manual  approaches  to  testability  assessment,  yet  are 
easily  automated  into  an  Interactive  format  for  the  designer  to  input  design  features  to 
allow  testability  grading.  However,  significant  engineering  analysis  Is  still  required.  Two 
checklists  of  that  type  are  the  RADC  PCB  Testability  Design  Rating  System  and  the  MIL- 
STD-2165  Appendix  B  Checklist.  The  original  RADC  PCB  rating  system  was  limited  to 
lower  density  digital  board  applications,  whereas  MIL-STD-2165  Appendix  B  covers 
analog,  digital.a  d  hybrid  applications  from  module  to  system  level.  An  updated  RADC 
PCB  rating  system  now  under  development  will  be  expanded  to  cover  all  modem  digital. 
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analog  and  hybrid  PCBs.  Tha  RADC  rating  systam  haa  fixad  Itama  of  waighting,  wharaaa 
MIL’STD>2165  Appandix  B  allowa  aubjactiva  traating  of  Itama  and  waighting  valuaa.  Both 
chaokliats  can  ba  utillzad  aaiiy  in  daaign. 

Logic  modala  hava  oonaidarabla  auccaaa  and  validity  othar  than  In  support  of 
tha  taatabiilty  discipllna.  Including  logiatioa,  fault  Isolation,  Intagratad  diagnostics,  and 
maintainability.  Tha  logic  modal  algorithms  ara  of  varying  sophistication  and  validity, 
although  tha  mathodology  for  dafining  dapandancias  ara  similar. 

Logic  modals  systams  for  tastablllty  ara  appiicabla  to  analog,  digital,  and  hybrid 
applications.  Thay  can  ba  modalad  at  tha  componant,  board,  or  modula  subsystam  and 
systam  laval.  Ona  limitation  of  this  broad  approach  Is  that  avary  Ham  la  Idantlflad  as  a  box 
with  Inputs  and  outputs.  Thus,  box  complaxlty  might  ranga  from  and  OR  gata  to  a 
complata  mlcroprooassor.  Tha  sama  variations  appllas  to  tha  linas  batwaan  boxas. 
Critical  signals,  such  as  a  clooK  or  a  tri*stata  bus  ara  not  mora  Important  than  any  othar 
llna.  Two  of  tha  mora  wall-known  modals  ara  Logic  Modaling  (LOQMOD)  and  Systam 
Tastablllty  And  Malntananoa  Program  (STAMP).  Both  ara  matura  In  natura,  but  aach  la 
tiad  to  a  spacHIc  vandor  at  tha  prasant  tima. 

Algorithmic  approachas  ara  parhaps  tha  most  sophlstloatad  approach.  SCOAP 
saams  to  usually  parform  wall,  but  haa  had  soma  library  limitations  In  tha  Important  araa 
of  CMOS  prImHIvas.  Soma  CAE  workstation  vandors  ara  including  modiflad  varaiona  of 
SCOAP  for  up*front  tastabllHy  anaiysas.  Daisy  workstations  Includa  tha  Daisy  Tastablllty 
Analyzar  (DTA)  paokaga,  and  QE/CALMA  workstations  Includa  tha  Controllability* 
Obsarvablllty*Pradlctablllty*Ta8tablllty  Raport  (COPTR)  packaga.  Both  hava  Improvad  on 
tha  basic  SCOAP,  via  top-down  modaling  and  larga  davloa  modal  llbrarlas  of  tha  mora 
common  1C  typas.  QanRad  also  has  a  paokaga  callad  HITAP,  which  Is  basad  on  tha 
Computar-Aldad  Maasura  for  Logistic  Tastablllty  (CAMELOT)  algorithm. 

Anothar  major  Issua  surrounding  inharant  tastabllHy  assassmant  Is  that  many  of 
tha  automatad  tools  which  axist  ara  propriatary.  This  propriatary  natura  of  tha  tools 
oraatas  Implamantatlon  problams  from  both  a  cost  and  a  contractual  point  of  vlaw.  OHan, 
tha  bast  approach  la  to  utillza  a  nonpropriatary  automatad  tool  for  Inharant  tastablllty 

assassmant. 

Prior  to  tha  PSD  phaso,  tha  dasign  or  tast  anginear  should  davalop  a  total 
stratagy  for  conducting  Inharant  tastablllty  assassmant  on  all  systams,  subsystams,  ate. 
Basad  upon  tha  availability  and  applicability  of  currant  Inharant  tastablllty  assassmant 
approachas.  It  Is  anticipated  that  combination  of  tools  and  tachniquas  will  ba  raquirad  to 
form  a  totally  comprahanalva  maasuramant  capability  in  araas  whara  an  automatad 
capability  Is  not  avallabla,  usa  tha  basallna  of  existing  models  to  make  modifications  to 
provide  tha  total  capability  raquirad. 
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dl 


An  •valuitlon  crittrla  for  Inharant  taalabllity  aatasamant  tools  and  taohniquat 
should  ba  davalopad  basad  upon  spaolflo  aystain  and  subsystam  spaolflo  naads.  Tha 
following  list  of  avaluatlon  crKarla  Is  racommandad: 

0  Automation;  dagraa  of  automation 

0  Propiiatary  natura 

0  Usar  friandllnass 

0  Automatad  link  to  dasign  data  basa 

0  Aocaptablllty  of  output  to  tha  govammant 

0  Costofuaa 

0  Availability  (ourrantly  avallabla  or  undar  davalopmant) 

0  Quality 

0  SanaHIvlty  to  Kay  taatabllHy  faaturas 

0  Faadbaok  providad  (doas  It  raoommand  daoign  fixaa?) 

0  Comprahansivanaaa  (digital,  analog,  RF,  VH8IC,  maohanloal,  ato.) 

0  Qanaral  taohnlquaa;  prinolplas  usad 

$ 

0  Link  to  taat  affaotivanaas  pradloMon  laohniqua 
o  Output  raports 
0  Scoring  mathodology 
0  Applicability  to  chip,  board,  subsystam 
TIST IPF8CTIVSNI8S 

Tha  saoond  typa  of  analysis  daals  with  last  affsotivanass.  Traditional 
approaches  to  datarmlning  tast  affactivanass  call  for  tha  ganaratlon  of  fast  aaquanoaa  at 
tha  completion  of  tha  dasign  phase  and  a  maasura  or  maasuraa  mada  of  their 
affactivanass.  Tha  analysis  naad  not  wait  on  tha  complatlon  of  BIT  and/or  off-line  TPS 
software.  Modeling  Is  encouraged,  since  this  approach  can  analyze  tast  affactivanass  on 
a  large  number  of  postulated  faults  prior  to  Incorporating  tha  tast  stimulus  In  either  an 
ambaddad  or  off-line  program.  Tha  results  of  tha  analysis  can  feed  forward,  so  as  to 
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lnflu«no«  BIT  or  TPS  software  design,  and  feed  backward  to  Influence  possible  redesign 
of  the  primary  system  to  Improve  Its  testability.  Test  effsctivensss  measures  have 
traditionally  Included: 

o  Fault  coverage 

0  PauH  resolution 

0  Fault  detection  time 

0  Fault  Isolation  time 

Computer  programa  are  used  to  Input  (via  software)  a  large  number  of  faults 
Into  the  software  model  of  the  hardware  Hem  (UUT).  The  response  of  the  simulated  Item 
to  the  test  sequence  Is  then  evaluated,  given  the  presence  of  the  simulated  faults.  Fault 
detection,  resolution,  etc.,  are  automatically  ascertained.  Moat  modern  Automatic  Test 
Program  Generation  (ATPQ)  and  simulation  systems  have  vary  efficient  fault  simulatlott 
capabilities.  The  HITS  system,  for  example,  runs  a  concurrent  fault  simulation  to  greatly 
speed  the  process.  The  usefulness  of  this  approach  in  measuring  test  effectiveness 
depends  on  the  adequacy  of  the  models  (hardware  item  model  and  fault  modal)  to 
accurately  reflect  the  reaLwoiid  sHuatlon,  Modeling  must  be  achieved  at  a  level  of  detail 
that  allows  all  known  and  statistically  signllloant  failure  modes  to  be  Included. 

Although  commonly  accepted,  the  application  of  these  measures  is  In  various 
stages  of  matuilty,  based  upon  the  equipment  composition  (I.e.,  digital,  analog,  radio 
frequency  and/or  mechanical).  At  this  time,  the  spplloatlon  experience  has  been 
concentrated  In  the  area  of  digital  Implementations.  However,  even  In  this  area, 
significant  additional  effort  will  be  required  In  order  to  relate  these  measures  to  operational 
performance.  The  degree  of  spplloatlon  of  test  effectiveness  measurement  techniques  to 
the  remainder  of  the  listed  equipment  types  has  been  quite  limited  to  date.  IDS8,  the 
Navy's  Integrated  diagnostics  program,  has  recognized  thie  need  and  has  an  active 
diagnostic  tool  development  program  underway.  One  of  these  tools,  the  Weapon  System 
TestabilHy  Analyzer,  Is  structured  to  address  test  effectiveness  measurement,  as  well  as 
inherent  testability  assessment. 

Effective  and  reallstlo  fault  modeling  is  a  key  element  In  the  development  of  the 
simulation  capability  needed  to  support  the  development  of  either  an  ATPQ  or  an 
automated  test  effeotlvenesa  measurement  tool.  However,  H  Is  anticipated  that  no  single 
fault  model  and/or  simulator  will  be  applloeble  to  the  broad  range  of  equipments  to  bo 
employed  wHhln  a  complex  system;  therefore,  a  combination  of  models  will  be  required  to 
meet  the  requirement  for  automated  determination  of  fault  detection  and  Isolation  levels. 

For  False  Alarm  estimation,  a  procedure  which  Is  documented  In  a  report 
(RADC>TR*87>55)  entitled  "Predictors  of  Organizational  -  Level  Testability  Attributes* 
developed  prediction  equations  for  various  testability  related  parameters.  Rather  than  try 
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to  dovtiop  tn  tquatlon  to  prodlot  Falio  Alarm  Rata  (FAR)  diractly,  an  approach  was  taKon 
to  predict  the  CND  rata  alnoa  this  parameter  should  closely  track  FAR.  The  following 
details  a  prediction  method  for  CND  rate.  Note  that  this  Is  a  model  based  on  empirical 
data  from  avionics  equipment  of  the  mld*1 080's  era  and,  aa  Is  the  case  with  all  models, 
care  must  be  taken  In  using  the  model  for  new  technology  or  applloatlons. 

The  equation  for  CND  rate  followa: 

CND  RATE  -0.0028  4  0.376*FLRRATE 

♦2.6  E-5TRAN8IENT  ♦  6.9E-1 1  *TC7 

The  variable  FLRRATE  accounts  for  the  LRU  Failure  Rate. 

The  variable  TRANSIENT  attempto  to  characterize  the  tendency  of  an  LRU  to 
exhibit  Intermittent  failures  resulting  from  marginal  or  degrading  components. 

The  variable  TC7  numerically  characterizes  the  likelihood  of  a  ar^eak  circuit 
existing  In  an  LRU. 

TRANSIENT  •  (IC'S  •••  2*RE8iSTOR3  41  *RELAY8  *  2*CAPACITOR8 
•  OTRANSISTORS)/#  of  SRU's 

TC7  -  INTERCONNECTS*(iC'a  •  160*RELAY3 
-  060*8WITCHE8  ♦  30*TRAN8ISTOR8) 

Where; 

RELAYS  -  Total «  of  Relays  In  LRU. 

CAPACITORS  M  Total  #  of  Capacitors  In  LRU. 

RESISTORS  -  Total  #  of  Resistors,  both  fixed  and  variable,  in  LRU. 

TRANSISTORS  ■  Total  #  of  discrete  translstora.  Including  FETs,  Bipolar,  etc.  that  are  In 
LRU  design. 

IC'S  ■  Total  #  of  integrated  circuits  In  LRU. 

SRU’s  «  Total  #  of  SRU's  that  compose  an  LRU. 

INTERCONNECTS  ■  Total  #  of  electrical  interconnects  used  to  mats  SRU's  to  the  host 
LRU. 

SWITCHES  -  Total  #  of  swHches  in  the  LRU  design. 


4-8 


IN-PROCESS  TESTABIUTY/DIAONOSnC  ANALYSIS  REQUIREMEINT  #4.1 


Sptciflos  about  tha  davelopmant  or  application  of  thia  aquation,  or  tha  aatimatlon  of  tha 
Input  paramatart  can  ba  found  in  tha  abova  rafarancad  raport. 
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CHECKLIST 

QT  Does  the  analyele  of  teetobllity/dlagnottle  raquiramente 
addraaa  oil  major  aupport  diacipllnaa? 

Off-llna  ATE 
Embedded  dlognoetloe 

Manpower  required  to  aupport  analyele  outpute 
Training  requiremente 
Information  requiremente. 

Are  all  anaiyaee  oomplete  and  unomblguoue? 

Do  they  meet  epeelficatlon  requiremente? 

E2f  le  the  analyele  integrated  and  coheelve?  Are  any 


Are  the  training.  Information,  and  manpower  require¬ 
mente  odequotely  eeoped  and  epeclfleo  to  eupport  the 
technical  complexify  of  the  eubjeot  end  Item  in  Ite 
operationol  environment? 

Have  available  toole  been  eelected  and  ueed? 


MAINTAINABILITY  DEMONSTRATIONS 


REQUIREMENT  #4.2 


WEAPON 
SYSTEM 
ACQ.  PHASE 


WEAPON 

SYSTEM 

ACTIVITIES 


OPER.  CONCEPT  DEM/ 

REQMTS.  EXPLOR.  VAL 


PROD/ 

DEPL 


Maintainability  Damonatratlona  art  parformad  In  aooordanoa  with  tha 
appropriata  damonitratlon  mathod  oontalnad  In  MiL-8TD>471A.  Notloa  2  of  MIL*STD* 
471 A  (USAF)  contains  raquiramants  for  damonstratlon  and  evaluation  of  ayatam 
BIT/axtarnal  taat/fault  laolatlon/tastability  attrlbutaa.  This  mathod  will  damonatrata  tha 
Intagratlon  of  tha  diagnostic  capability  for  tha  ayatam  (a.g.,  Intagratlon  of  ambaddad  taat 
softwara  and  hardware  tachnlquaa,  automatic  and  manual  tost,  BIT/SIT,  training  lavala, 
human  Intarfacas).  Tha  Maintainability  Damonatratlona  avaluata  tha  diagnostic 
parformanca  of  tha  ayatam  with  raapaot  to  tha  diagnostic  parfcrmanca  criteria  and 
ob|aotlvas  astabllahad  In  accordance  with  MtL-STD-470  (Maintainability  Program)  and 
MIL>STD>2165  (Testability  Program)  and  tha  raquiramants  for  an  Integrated  diagnostics 
capability  damonstratlon  contained  In  tha  PSD  SOW. 

gBO^SSMBB 

Tha  Integrated  diagnostics  process  Increases  tha  scope  of  maintainability 
demonstrations.  It  Is  tha  Contractor  Program  Manager’s  responsibility  to  ensure  that  this 
Increased  scope  Is  understood  and  Implamantad.  It  Is  tha  designers  responsibility  to 
design  tha  damonstratlon,  evaluate  tha  results  and  taka  tha  necessary  corrective  actions. 

Tha  scope  of  Maintainability  Demonstrations  Includes; 

1 .  Demonatraticn  of  Testability  Paramatars 
•  BIT  Fault  Oetactlon 
-  BIT  Isolation  Tima 
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I 


•  BIT  Faun  Isolation  Laval  (Ambiguity  Group) 

2.  Damonstratlon  of  Taat  Effactivanass  (ATE)  (MIL«STD>2077) 

•  ATE  Fault  Oataotlon 

•  ATE  Fault  Isolation  Tima 

-  ATE  Fault  Isolation  Laval  (Ambiguity  Group) 

.  UOT/ATE  Compatibility 

3.  Damonstratlon  of  Taohnioal  Information 

•  Taohnioal  Information  Aooass  Tima 

•  Taohnioal  Information  Ralativa  Aooass  Easa 

-  Taohnioal  Information  Format 

•  Taohnioal  Information  Usability 

4.  Damonstratlon  of  Tralning/Skllls 

•  Ralatlonahip  batwaan  maintananoa  prooaduras  and  skills 

•  Ralatlonship  batwaan  formal  training  and  actual  maintananoa  job 
flow. 

5.  Damonstratlon  of  Vartloal  and  Horizontal  Intagratlon 

-  Compatibility  and  Consistaney  of  diagnostic  damonstratlon  results 
batwaan  maintananoa  lavals  and  among  thalr  raspactlva  diagnostic 
alamanta. 

Unfortunataly,  tha  ability  to  carry  out  a  single  damonstratlon,  or  even  a 
sarlas  of  demonstrations,  to  prova/avaluata  this  level  of  diagnostic  capability  Is 
dependant  upon  having  all  of  tha  diagnostic  alamants  available  for  tha 
maintainability  demonstration.  While  this  should  always  be  tha  goal,  It  may  not  be 
feasible  for  all  of  tha  above  due  to  development  schedules,  UUT  design  Instsbillty, 
data  availability  and  other  overall  program  constraints.  (Note  that  this  Is  a  primary 
reason  for  a  Dlagnostios  Maturation  Program.) 

Typically,  tha  oontraotor  prepares  a  Maintainability  Damonstratlon  Plan 
early  In  tha  PSD  Phase  and  that  plan  Is  subject  to  government  review  and  approval. 
Tha  designer  should  taka  advantage  of  this  opportunity  to  design  the  Maintainability 
Demonstrations  to  Include  tha  factors  cited  above.  This  can  have  a  significant  cost- 
savings  impact  on  tha  Diagnostics  Maturction  Program  requirements. 
Maintainability  Demonstrations  represent  the  first  major  opportunity  to  evaluate  the 
level  of  diagnostic  capability  achieved.  Also,  Maintainability  Demonstrations  can  be 
conducted  early  enough  to  Implement  corrective  action  cost-effectively. 
Demonstrations  are  conducted  while  the  system  is  still  considered  to  be  In  the 
Development  Phase.  After  tha  demonstrations  are  completed,  the  relative  cost  of 
identifying  deficiencies  and  implementing  corrective  action  Is  significantly  inersaaed. 
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A  significant  milestone  of  'Government  Acceptance'  occurs  upon  satisfactory 
completion  of  Maintainability  Demonstrations,  After  this  milestone,  costs  for 
identification  and  resolution  of  diagnostic  deficiencies  may  be  subject  to  contract 
interpretation  and/or  negotiation.  The  total  strategy  for  the  test  and  evaluation  of  the 
diagnostic  capability  is  placed  on  the  TEMP,  and  detailed  in  the  Integrated  Test 
Plan. 


Based  upon  the  selected  scope  of  the  Maintainability  Demonstration, 
procedures  from  MIL-STD-471  are  utilized  and  adapted  for  the  scope.  These 
procedures  are  documented  In  the  Maintainability  Demonstration  Plan.  The  results 
of  the  Maintainability  Demonstration  are  documented  In  a  technical  report  • 
Maintainability  Demonstration  Results. 

Concurrent  Dennonatratlona 

The  overall  diagnostic  capability  Is  the  sum  of  a  variety  of  diagnostic 
elements.  Therefore,  a  requirement  should  be  established  for  early  demonstration 
of  the  entire  diagnostic  capability  produced  by  the  Integration  of  all  of  these 
diagnostic  elements.  This  is  referred  to  as  concurrent  demonstrations,  where  the 
timing  of  various  diagnostic  element  demonstrations  are  planned  and  scheduled  for 
concurrency  so  that  the  Integrated  capability  can  be  assessed. 

Each  element  of  the  diagnostic  capability  must  be  demonstrated,  as  well 
as  the  result  of  the  combining  or  integration  of  the  elements.  For  example,  a 
demonstration  of  subsystem  BIT  may  prove  fault  detection  and  Isolation  levels.  A 
demonstration  of  ATE  may  prove  external  fault  detection  and  isolation  levels.  A 
concurrent  demonstration  of  these  two  diagnostic  elements  will  prove  the  ability  of 
the  ATE  to  use  BIT  circuitry,  to  use  BIT  results,  and  the  consistency  of  test  results 
between  BIT  and  ATE.  By  concurrent  demonstration,  the  whole  Is  greater  than  the 
sum  of  the  parts.  A  significant  set  of  factore  related  to  the  result  of  the  Integration  of 
the  diagnostic  elements  must  be  evaluated  eariy. 
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C2f  Does  the  demonstration  plan  provide  a  100%  fault 
coverage  capability  across  ail  levels  of  maintenance? 

o  0rgani2ational  Level 
e  Intermediate  Level 
•  Depot  Level 

of  Are  the  failure  modes  to  be  demonstrated  and  criteria 
to  be  utilized  adequately  specified  for  each  maintenance 
level?  Will  an  adequate  number  of  faults  be  inserted 
as  required  by  MIL-STD-471  to  statistically  prove 
that  FD/FI  requirements  are  or  are  not  met? 

of  Is  the  demonstation  structured  to  provide  an 
evaluation  of  the  diagnostic  capabilities  as 
an  integrated  system? 

ESf  Do  the  subject  plans  demonstrate  an  integrated, 

cohesive  maintenance  flow  In  terms  of  demonstrating 
how  a  fault  would  be  detected  and  repaired?  Is  a 
systems  approach  to  the  maintenance  process  taken 
in  the  overall  approach  to  demonstration  planning? 
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CONDUCTINQ  DESIGN  REVIEWS 
OVERVIEW 

During  th«  acquisition  of  a  weapon  ayatem  there 
are  at  least  sight  formal  technical  reviews  t  d 
audits,  which  may  be  conducted  by  the  contractor 
for  the  Government  Program  Manager.  As  In  the 
diagnostic  design  process,  there  Is  a  tendency  to 
conduct  separate  reviews  and  audits  based  upon 
the  function  being  addressed.  This  particularly 
refers  to  logistics,  reliability,  maintainability, 
testability,  human  engineering,  and  safety. 
Integration  of  these  reviews  and  audits  to  address 
diagnostic  Issues  is  a  must.  MIL<STO«1521  Is  the 
prime  document  which  defines  the  Issues  to  be 
addressed  at  each  of  these  formal  reviews.  At 
present,  these  checklists  are  Inadequate  in  terms 
of  both  testability  and  diagnostics  and,  thus,  these 
reviews  and  audits  may  not  serve  their  purpose. 
Additional  guidance  must  be  given  to  both  the 
government  and  the  contractor  In  order  to  sllevlate 
this  problem. 

Informal  reviews  are  often  required.  Guidance  for 
these  Informal  reviews  can  be  drawn  from  formal 
review  guidance. 


TESTABILITY/ 

DIAGNOSTICS 


—I  PROGRAMMATIC  \ 
.  — H  REQUIREMENTS  | 

— H  design  i 


— j  ASSESSMENT  | 


— j  EVALUATION  | 


I— lij  maturation  I 


IMPQBTAHT  CONSIDERATIONS  TO  EE  ADDRESSED 


RfqmL 

5.1  Technical  reviews  and  audits  must  address  ell  facets  which  affect  the 
performance  of  the  diagnoatio  capability. 
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OPER.  CONCEPT  DEM/ 

ACOwisE 


WEAPON 

SYSTEM 

ACTMTIES 


DIAGNOSTIC 

ACTMTIES 


PROD/ 

DEPL 


DCP  PREL  DETAIL  lOTAE 
DESIGN  DESIGN 


A  A  A  A  A  A  A 

SDR  PDR  CDR  mR  PRR  FCA  PCA 


PIAGHQgnC  AGHYITY 

T«ohnloal  rtvltwt  and  audits  sr«  an  Important  factor  In  assuring  that  tha 
govsmmant  is  fumishad  with  a  weapon  tystam  whioh  meats  Hs  raquirsmants. 

PPQQBPVRB 

MIL'>STD-1621  lists  10  formal  taohnioal  reviews  and  audits.  Of  these  10,  eight 
are  considered  critical  In  the  achievement  of  a  satisfactory  diagnostic  oapablllty.  The 
following  guidance  supplements  and  expands  the  guidance  contained  In  MIL*8TD*1521, 
Technical  Reviews  and  Audits  tor  Systems,  Equipments,  and  Computer  Software. 

Although  design  reviews  are  recognized  as  being  Important  to  verify  design 
before  production,  the  lacK  of  depth  In  these  reviews  Is  alarming.  The  cause  of  these 
inadequate  reviews  must  be  shared  by  both  the  contractors  and  the  government. 
Contractually,  the  government  rarely  requires  the  oontraotor  to  do  a  comprehensive 
technical  review,  and  tha  contractor  does  not  do  so  unless  required,  even  though  It  may 
be  cost  effective  from  his  point  of  view.  Even  when  the  right  words  are  used,  the  end 
results  depend  largely  on  corporate  policy  to  allooate  sufficient  resources  to  perform  a 
detailed  analysis  of  the  design  and  associated  processes.  The  designer,  obviously,  has 
an  Important  input  to  those  reviews.  Therefore,  It  follows  that  he  must  understand  the 
objectives  and  scope  of  these  reviews. 
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QUIPANCe 

Quidance  relating  to  these  various  reviews  Is  contained  in  the  appendices  to 
MIL-STD-1521 .  Because  these  appendices  do  not  address  all  aspects  of  testability  and 
diagnostics,  some  supplemental  Information  Is  Included  In  the  following  paragraphs. 

System  Requirements  Review  (8RR) 

The  objective  of  this  review  Is  to  sscertsln  the  adequacy  of  the  contractor’s 
efforts  In  defining  system  requirements.  It  will  be  conducted  when  a  significant  portion  of 
the  system  functional  requirements  has  been  eetabllshed. 

The  diagnostic  capability  review  portion  of  the  SRR  will  analyze  the  syetem 
Items  that  are  related  to  diagnostics.  The  following  Items  will  be  reviewed,  as  appropriate: 

0  Mission  and  Requirements  Analysis 
0  Functional  Flow  Analysis 
0  Preliminary  Requirements  Allocation 
0  System/Cost  Effectiveness  Analysis 
0  Trade  Studies 
0  Synthesis 

0  Logistic  Support  Analysis 
0  Specialty  Discipline  Studies 
0  Generation  of  Specifications 
0  Program  Risk  Analysis 
0  Integrated  Test  Planning 
0  Technical  Performance  Measurement  Planning 
0  Engineering  Integration 
0  System  Safety 
0  Human  Factors  Analysis 
0  Life  Cycle  Cost  Analysis 
0  Manpower  Requirements/Personnel  Analysis 
0  Milestone  Schedules. 

The  diagnostic  capability  review  should  address  the  Impact  of  the  results  of  the 
Items  listed  above  on  the  diagnostic  pieces  listed  below. 

0  Designed-ln  Reliability,  Prognostics,  and  Testability 
0  Self-Test,  Built-In  Test,  System  Integrated  Test 
0  Support  Equipment,  Maintenance  Aids 
0  Technical  Data 
0  Personnel  Skill  Requirements 
0  Training  and  Training  Devices. 
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Syttam  DMign  Ravlaw  (SDR) 

This  rtvitw  shall  bs  conductsd  to  svsiuats  tht  optimization,  eorralatlon, 
oomplatanass,  and  risks  assoolatad  with  tha  allooatad  taohnical  raquiramants.  Also 
Inoludad  Is  a  summary  rsvisw  of  tha  systam  anglnaarlng  procsss  which  produced  the 
allocated  technical  requirements  and  of  the  engineering  planning  for  the  next  phase  of 
effort.  Basic  manufacturing  considerationa  will  be  reviewed,  and  planning  for  production 
engineering  in  subsequent  phases  will  be  addressed.  This  review  will  be  conducted  when 
the  system  definition  effort  has  proceeded  to  the  point  where  system  characteristics  are 
defined  and  the  Configuration  Items  (Cl)  are  identified. 

Speolflo  diagnostic  considerations  relate  to: 

0  Optimizing  the  diagnostic  capability  (changes  aftsr  Dem/Val  usually  are  more 
costly  and  time  consuming) 

0  Preparation  of  a  Maturation  Plan 

0  Preparation  of  a  System  Specification  which  provides  a  capability  for 
addressing  100%  FD/FI  for  each  level  of  maintenance 

0  Allocation  of  diagnostic  requirements  for  each  diagnostic  element 

0  Review  of  the  software  requirements  specification  to  assure  that  embedded 
diagnostic  software  considerations  are  Included. 

Preliminary  Design  Review  (PDR) 

This  revisw  shsll  be  conducted  for  each  Configuration  Item  or  aggregate  of 
Configuration  Items  to;  (1)  evaluate  the  progress,  technical  adequacy,  and  risk  resolution 
(on  a  technical,  cost,  and  schedule  basis)  of  the  selected  design  approach;  (2)  detennine 
Its  compatibility  with  performance  and  engineering  specialty  requirements  of  the  Hardware 
Configuration  Item  (HWCI)  development  specification;  (3)  evaluate  the  degree  of  definition 
and  assess  the  technical  risk  associated  with  the  selected  manufacturing 
methods/processes;  and,  (4)  establish  the  existence  and  compatibility  of  the  physical  and 
functional  interfaces  among  the  Configuration  Item  and  other  Items  of  equipment,  facilities, 
computer  software,  and  personnel.  For  CSCIs,  this  review  will  focus  on;  (1)  the 
evaluation  of  the  progress,  consistency,  and  technical  adequacy  of  the  selected  top-level 
design  and  test  approach;  (2)  compatibility  between  software  requirements  and 
preliminary  design;  and,  (3)  on  the  preliminary  version  of  the  operation  and  support 
documents. 

In  addition,  the  following  Kerns  In  the  diagnostic  area  should  be  presented  at  the 
appropriate  depth  for  review. 
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o  Preliminary  Failure  Modat  and  Effaota  Analyaia 

0  Daalon  data  analysts  for  BIT/SIT  Intagratad  diagnostics,  Including 
raquiremants  and  pralimlnary  design  varlfloatlon  rtsuHa 

0  Maintananca  concapt  for  tha  portion  of  tha  systam  baing  ravlawad  and  Its 
tracaablllty  to  tha  systam  maintananca  concapt 

0  Oparatlonal  maintananca  functions 

0  Rasutta  of  tha  analysis  of  tha  Inharant  (Intrinsic)  tastabilKy  of  tha  pralimlnary 
dasign 

0  Allocation  of  qualHativa  and  quantHatlva  raquiramanta 

o  Critaria  for  axtamal  diagnostic  alamants 

0  Trada>off  studlaa 

0  Cost/Systam  Effactivanass  Modaling  and  Ufa  Cyola  Coat  Analysis 

0  Pralimlnary  Logistic  Support  Analysis,  Including  tasK  analysis  snd  ralatad 
parsonnal  and  support  aquipmant  Infonnation 

0  Evaluation  of  aKamatlvas 

0  Taat  and  avaluatlon  plans. 

Critical  Daaign  Ravlaw  (CDR) 

This  ravlaw  shall  ba  oonduotad  for  aaeh  Configuration  Itam  whan  datali  dasign  la 
assantlally  oomplata.  Tha  purpose  of  this  ravlaw  will  ba  to;  (1)  datarmlna  that  tha  detail 
design  of  tha  Configuration  Itam  under  ravlaw  satiaflas  tha  performance  and  anglnaarlng 
spaclalty  raquiremants  of  tha  HWCI  davalopmant  spac  .^ications;  (2)  establish  tha  detail 
design  compatibility  among  tha  configuration  and  other  Items  of  aquipmant,  facilities, 
computer  software  and  personnel;  (3)  asaasa  Configuration  Item  risk  areas  (on  a 
technical,  cost,  and  schedule  basis);  (4)  assess  tha  results  of  tha  produciblllty  analyses 
conducted  on  systam  hardware;  and,  (6)  ravlaw  tha  preliminary  hardware  product 
specifications.  For  CSC  Is,  this  ravlaw  will  focus  on  tha  determination  of  tha  acceptability 
of  tha  detailed  design,  parformanca,  and  test  oharaotaristlcs  of  tha  dasign  solution,  and  on 
tha  adequacy  of  the  operation  and  support  documents.  Tha  CDR  shall  ba  conducted  on 
each  Configuration  Itam  prior  to  fabricatlon/productlon/codlng  release  to  ensure  that  tha 
detail  dasign  solutions,  as  raflactad  in  tha  Draft  Hardware  Product  Specification,  Software 
Detail  Dasign  Document  (SDDD),  Data  Base  Dasign  Dor;umant(a)  (DBDD),  Interface 
Dasign  Documont(s)  (IDD),  and  anglnaarlng  drawings,  satisfy  requirements  established  by 
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by  th«  Hardwart  Davalopmant  Spaoltloatbn  and  Software  Top-Level  Dealgn  Document 
(STLDD).  The  CDR  ahall  be  held  after  the  Computer  Software  Operator'a  Manual 
(C80M),  Software  Uaer'i  Manual  (SUM).  Computer  Syatem  DIagnoitIo  Manual  (CSDM), 
Software  Programmer'a  Manual  (SPM),  and  Firmware  Support  Manual  (FSM)  have  been 
updated  or  newly  releaaed. 

It  II  desired  at  each  COR  to  provide  as  much  assurance  as  practicable  that  all 
diagnostic  requirements  are  satisfied:  I.  e.,  that  100%  diagnoatic  capability  will  exist  for 
each  Cl  In  the  system.  While  it  probably  will  not  be  practicable  to  certify  that  this  will  exist, 
the  following  data  should  be  presented  as  an  extension  of  the  Information  presented  at 
the  PDR. 

0  Detailed  fault  deteotlon/fault  Isolation  analyses  that  Identify  the  extent  to 
which  BIT/SIT  detect  and  isolate  faults  and  which  Identify  those  failures  that 
will  require  support  equipment  and/or  manual  methods  to  detect  and/or 
Isolate. 

0  Diagnostic  allooatlona  In  Port  II  Cl  specifications  to  the  LRU  and  SRU  level. 
Traoeability  of  these  requirements  to  the  Part  I  Cl  System  Specification 
should  be  demonstrated.  Note:  Flexibility  to  reallocate  diagnostic 
allocations  until  product  baseline  Is  established  at  PCA  should  be  provided 
within  the  envelope  of  system  requlrenwnts. 

0  Definition  of  the  maintenance  plan/oonoept  for  the  Cl,  together  with 
supporting  L8A  documentation,  Including  support  requirement  and  leveLof- 
repair  analysis  results.  Logistic  simulation  results  should  be  presented  to 
substantiate  the  plan/oonoept. 

0  Presentation  of  testability  analyals/assessment  results  for  the  Cl  design  to 
substantiate  the  fault  detection/  fault  Isolation  analysis. 

0  Early  program  failure  Identification,  prevention,  and  detection  analyses 
applicable  to  the  Cl  should  be  presented  to  assist  In  verifying  diagnostic 
capability. 

0  Review  detailed  Maintainability  Demonstration  Plan  for  Inclusion  of 
diagnostic  capability  test  requirements 

0  Appropriate  updates  to  the  Items  reviewed  during  the  PDR. 

Teat  Readineea  Review  (TRR) 

This  review  Is  conducted  for  each  CSCI  to  determine  whether  the  software  test 
procedures  are  complete  and  to  assure  that  the  contractor  is  prepared  for  formal  CSCI 
testing.  Software  test  procedures  are  evaluated  for  compliance  with  software  teat  plans 
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and  dasorlptiont  and  forr  in  aooompilahing  taat  raquiramanta.  At  TRR  tha 
oontraotlng  aganoy  alio  ra«aulta  of  informal  aoftwara  taating  and  any  updataa  to 
tha  oparatlon  and  aupport  i.  A  auooauful  TRR  it  pradleatad  on  tha  oontraoting 
aganoy't  datarmlnation  thivara  taat  procaduraa  ar^  Informal  taat  raaulta  form  a 
aatlafactory  batia  for  prooaformal  CSC!  taating. 

Tha  diagnoatic  a  tha  ayttam/CI  TRR(a)  thall  ba  a  formal  ravlaw  of  tha 
oontraotor'a  raadinaaa  to  tal  diagnottioa>ralatad  CSCI  taating.  It  la  conduotad 
aftar  tha  aoftwara  taat  proca  avaliabla  for  diagnoatloa-ralatad  CSCI,  auoh  aa  Cl 
BIT.  Syatam  BIT,  SIT,  atcar  oomputar  ayatam  oomponant  (CSC)  Intagration 
taating  la  oomplata. 

Tha  Itama  to  ba  nduda: 

1.  Raquiramant -• 

Any  ohangaiSIT,  or  taatabiiity  raquiramanta  oontainad  In  tha 
ayatam/CI  Saquiramant  Spaoifioatlon  or  Intarfaoa  Raquiramanta 
Sipaolftoatlon  not  baan  approvad  and  whioh  impact  CSCI  taating. 

2.  DaaIgnChani 

Any  ohangao  tha  BIT,  SIT,  or  taatabiiity  daaign  paramatara 
oontainad  in  ira  Top-Laval  Daaign  Doeumant  (STLDD),  Softwara 
Datail  Daaignrt  (8DDD),  Intarfaoa  Daaign  Dooumant(a)  (IDD)  ainoa 
tha  PDR  and  h  Impact  CSCI  taating. 

3.  Softwara  Taab  Daaorlptlona  - 

Any  ohangaaibaddad  diagnoatio  alamant  portion  of  tha  approvad 
Softwara  TaafP)  and  Softwara  Taat  Daaoriptiona  (STD). 

4.  Softwara  Taataa  •• 

Taat  prooaduuaad  in  conducting  BIT  and/or  SIT  taat  affaotivanaaa 
validation  aa  a  CSCI  taating,  Including  rataat  procaduraa  for  taat 
anomallaa  amna. 

5.  Intagration  Ta  Procaduraa,  and  Raaulta  - 

Any  ambaddoatio  alamant  CSC  (a.  g.,  BIT  oomponanta,  SIT 
oomponanta)on  taat  oaaaa,  and  procaduraa  uaad  In  conducting 
Informal  dlagmant  CSC  Intagration  taata  and  tha  taat  raaulta. 
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6.  Software  Tast  Ratouroai  •• 

Status  of  any  softwara  tast  rasourcas  that  ara  raqulrad  spacifically  for 
ambaddad  diagnostic  alamant  C9CI  tasting.  Such  rasourcas  may  Includa 
diagnostic  tast  personnal  and  supporting  tast  softwara  and  materials, 
Including  software  tast  tool  qualification  and  review  of  the  traceability 
between  raquiramants  and  their  associated  tests. 

7.  Tast  Limitation  - 

Identification  of  all  softwara  tast  limitations  asaoolatad  with  ambaddad 
diagnostic  alamant  C8CI/CSC  tasting. 

8.  Softwara  Problama  - 

Summary  of  ambaddad  diagnoatio  alamant  software  problem  status, 
Including  all  known  disorapanoias  of  the  C8CI  and  tast  support  softwara. 

Schedules  - 

Schedules  for  the  remaining  ambaddad  diagnostic  alamant  softwara 
mllestonas. 

Production  Raadinaaa  Review  (PRR) 

This  review  Is  intended  to  determine  the  status  of  completion  of  the  spaoiflo 
actions  which  must  be  satisfaotorlly  accomplished  prior  to  executing  a  production  go* 
ahead  decision.  The  review  Is  aooomplishad  in  an  Incremental  fashion  during  the  Full- 
Scale  Development  Phasa-usually  two  initial  reviews  and  one  final  review,  to  assess  the 
risk  in  exercising  the  production  go-ahead  decision.  In  Its  earlier  stages,  the  PRR 
oonoems  Itself  with  gross-level  manufacturing  oonoerns.  such  as  the  need  for  Identifying 
high-rlsk/low-ylald  manufacturing  processes  or  materials  or  the  requirement  for 
manufacturing  development  effort  to  satisfy  design  requirements.  The  reviews  become 
more  refined  as  the  design  matures,  dealing  with  such  concerns  as  production  planning, 
facilities  allocation.  Incorporation  of  produoibility-orlented  changes.  Identification  and 
fabrication  of  tools/test  equipment,  long-lead  Item  acquisition,  etc.  Timing  of  the 
Incremental  PRRs  Is  a  function  of  program  posture  and  Is  not  specifically  looked  Into  other 
reviews.  The  diagnostic  consideration  concerns  the  use  of  any  of  the  external  diagnostic 
elements  (e.g.,  ATE)  In  the  production  testing  environment. 

Functional  Configuration  Audit  (FCA) 

This  is  a  formal  audit  to  validate  that  the  development  of  a  Configuration  Item 
has  been  completed  satisfaotorlly  and  that  the  Configuration  Item  has  achieved  the 
performance  and  functional  characteristics  specified  In  the  functional  or  allocated 
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configuration  Idantlflcatlon.  In  addition,  tha  complatad  operation  and  support  documents 
shall  be  reviewed. 

The  FCA  Is  normally  conducted  on  a  prototype  or  preproduction  Item.  The  FCA 
validates  that  tho  Item  meets  Its  specified  performance  requirements  and  Is  ready  for 
production  and  acceptance  into  Air  Force  inventory.  It  Is  lmp«(rative  that  the  diagnostic 
capability  be  validated  against  Its  specified  performance  requirements,  so  that  any 
diagnostic  capability  deficiencies  can  be  Identified  and  corrected  before  the  Item  proceeds 
into  production  and  is  then  deployed. 

Physical  Configuration  Audit  (PCA) 

This  Is  a  technical  examination  of  a  designated  Configuration  Item  to  verify  that 
the  Configuration  Item  *as  built"  conforms  to  the  technical  documentation  which  defines 
the  Configuration  item. 

After  successful  completion  of  the  audit,  all  subsequent  changes  to  the 
diagnostic  elements  are  processed  by  an  engineering  change  action.  The  PCA  also 
determines  that  the  diagnostic  element  acceptance  testing  prescribed  b>  tne 
documentation  Is  adequate  for  acceptance  of  the  production  units  by  quality  assurance 
activities.  The  procedures  for  conducting  a  PCA  are  contained  in  MIL-STD>1521, 
Appendix  H.  Sample  PCA  Certification  Attachment  Checklists  are  contained  In  MIL*8TD* 
1521,  Appendix  I. 
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CHECKLIST 


□f  Art  th«  dMigntrt  Included  In  the  rtvitwt  ond  audits 
so  th^  eon  chollangs  ths  design  and  assess  risks? 


□f  Are  the  dtogneetle  reviews  held  as  an  integral 
port  of  the  prime  system  review,  but  In  ‘  ^ 

a  timely  manner  that  allows  change  (If  necessory) 
in  the  diagnostic  equipment  or  process? 


5<11 


BtamL 

6.1  Provldt  Input  to  th#  proporttlon  of  >n  Intogratod  Taat  Plan,  whioh 
Inoludaa  tha  raquiramanta  for  a  Taat  and  Bvaluatlon  Maatar  Plan. 

6.2  Aaaura  that  formal  taat  and  avaluatlona  addraaa  tha  antira  diagnoatio 
capability. 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 
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FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTIVITIES 

A  A  A  A 

- - - ^  CDR 

CONTRACT 

AWARD 

DIAONOSDC 

ACTIVITIES 

A  A  A 

rrup  temp  TEMP 

TEMP  update  update 

DIA0N08TI0  ACTIVITY 

Th«  r«qulr«mtnts  for  dlagnoitios  toil  and  avaluatlon  art  Id# ntiflad,  lohadulad 
and  Intagratad  Into  tha  Taet  and  Evaluation  Maatar  Plan  (TEMP). 

prqO^PVRP 

Tha  TEMP  la  a  living  dooumant  normally  prcparad  by  tha  Contractor  Program 
Manager.  Ita  preparation  goes  through  many  Iterations  as  tha  program  proceeds  through 
Concept  Exploration  Phase  studies,  Demonstration  and  Validation,  Full-Scale 
Development,and  Production.  With  each  Iteration,  plans  for  diagnostic  Test  and 
Evaluation  (T&E)  should  become  flnnei',  better  defined,  and  with  target  milestone  dates 
attached. 


Because  test  and  evaluation  is  a  major  cost  and  schedule  driver,  adequate 
planning  Is  essential  long  before  It  starts.  Test  planning  between  subopntraotors,  the 
prime  contractor,  and  the  government  should  start  with  program  Initiation.  To  ensure  a 
successful  Integrated  test  program,  close  coordination  Is  required  between  the 
government,  the  prime  contractor,  and  all  subcontractors.  The  designer  should 
understand  tha  scope  and  methods  to  be  used  In  evaluating  the  product,  and  provide 
Inputs  to  the  TEMP,  which  promote  realism  In  these  tests. 
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L 


J 


QUIDANCE 

DoD  Directive  5000.3  requires  the  preparation  of  a  Teat  and  Evaluation  Master 
Plan  (TEMP).  The  TEMP  la  a  broad  plan  relating  test  objectives  to  required  system 
characteristics  and  critical  Issues,  and  is  a  top-level  document  used  at  major  milestone 
reviews  to  assess  the  adequacy  of  planned  teat  and  evaluation.  At  minimum,  It  addresses 
both  Development  and  Operational  Tost  and  Evaluation.  It  Is  Important  that  as  much  as 
possible  of  the  diagnostic  capability  be  Included  in  these  T&Es. 

Developmental  Test  and  Evaluation  (DT&E)  la  the  T&E  conducted  throughout 
various  phases  of  the  acquisition  process.  This  will  ensure  the  acquisition  and  fielding  of 
an  effective  and  supportable  system  by  assisting  In  the  engineering  design  and 
development  and  verifying  attainment  of  technical  performance  specifications,  objectives 
and  supportabllity. 

Developmental  Test  and  Evaluation  also  includes  T&E  of  components, 
subsystems,  preplanned  product  improvement  (P^l)  changes,  hardware-software 
Integration  and  related  software,  as  well  as  qualification  and  production  acceptance 
testing.  Test  and  evaluation  of  compatibility  and  Interoperability  with  existing  or  planned 
equipment  or  systems  Is  emphasized.  This  T&E  encompasses  the  use  of  models, 
simulations  and  testbeds,  as  well  as  prototypes  of  Full-Scale  Development  models  of  the 
system.  The  diagnostic  capability  associated  with  component,  assembly  and  subsystem 
DT&E  should  be  Included  in  these  T&E  activities. 

Qualification  Testing  is  the  part  of  DT&E  which  verifies  the  design  and  the 
manufacturing  process  and  provides  a  baseline  for  subsequent  acceptance  tests.  This 
accomplishes  two  separate  functions: 

(1)  Preproduction  Qualification  Tests  are  formal  contractual  tests  that  ensure 
design  Integrity  over  the  specified  operational  and  environmental  range.  These  tests 
usually  use  prototype  or  preproduction  hardware  fabricated  to  the  proposed  production 
design  specifications  and  drawings.  Such  tests  Include  contractual  reliability  and 
maintainability  demonstration  tests  required  prior  to  production  release.  At  a  minimum, 
embedded  diagnostics  capabilities  and  the  interfaces  to  external  diagnostic  elements 
should  be  tested  and  evaluated  during  preproduction  qualification  tests.  As  a  goal,  the 
capability  of  external  diagnostic  elements  should  aisc  be  tested  and  evaluated. 

(2)  Production  Qualification  Tests  ensure  the  effectiveness  of  the  manufacturing 
process,  equipment  and  procedures.  These  tests  are  conducted  on  a  sample  lot  taken  at 
random  from  the  first  production  lot,  and  are  repeated  as  the  process  or  design  Is  changed 
significantly,  and  when  a  second  or  alternate  source  is  brought  on  line.  These  tests  are 
also  conducted  against  contractual  requirements.  The  utilization  of  diagnostic  resources 
in  the  manufacturing  process  and  the  requirement  for  capture  of  diagnostic  data  from  the 
manufacturing  process  should  be  evaluated  during  production  qualification  testing. 
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The  completion  of  Preproduotion  Qualification  Test  and  Evaluation  before 
Milestone  III  decisions  Is  essential  and  will  be  a  critical  factor  In  assessing  the  system's 
readiness  for  production. 

Operational  Test  and  Evaluation  (OT&E)  Is  the  field  test,  under  realistic 
conditions,  of  any  item  (or  key  component)  of  weapons,  equipment  or  munitions  for  the 
purpose  of  determining  the  effectiveness  and  suitability  for  use  In  combat  by  typical 
military  users;  and  the  evaluation  of  the  results  of  such  tests.  Operational  testing  Is 
acoompllehed  In  an  environment  as  operationally  realistic  as  possible.  The  entire 
diagnostic  capability  should  be  assessed  during  OT\E  as  well  as  the  Integration  of  the 
diagnostic  ciipablllty. 

The  TEMP  must  clearly  specify  development  and  operational  test  events. 
However,  DT&E  and  OT&E  are  not  necessarily  aerial  phases  in  the  evolution  of  a  weapon 
system.  During  critical  acquisition  cycle  transitions,  elements  of  DT&E  and  OT&E  may  be 
combined  or  occur  In  parallel,  but  not  at  the  expense  of  either  development  or  operational 
test  realism  nor  before  sufficient  OT&E  can  reasonably  assure  that  the  system  Is  ready  to 
enter  dedicated  operational  testing.  DT&E  may  continue  Into  the  Production  and 
Deployment  Phase,  along  with  OT&E,  to  address  system  enhancements,  correction  of 
deficiencies,  or  modifications.  In  all  oases,  test  planning  for  all  test  phases  must  be 
addressed  In  the  system  TEMP. 

Test  and  evaluation  planning  is  initiated  at  the  Inception  of  the  development 
process  to  ensure  adequate  planning,  programming  and  budgeting  of  test  resources  and 
to  facilitate  test  sohedulinc  to  support  major  program  decision  milestones.  Reliability 
assurance  should  be  well  underway  before  the  Initiation  of  system  performance  tests. 
System  deficiencies  must  be  addressed  through  a  dynamic,  well*documented,  and  tightly 
managed  test-analyze*flx  and  retest  program.  The  evaluation  of  embedded  diagnostic 
elements  should  be  Injected  into  these  reliability  assurance  tests. 

A  TEMP  Is  required  for  ail  major  defense  acquisition  programs.  The  TEMP 
defines  and  Integrates  test  objectives,  critical  issues,  systems  characteristics, 
responsibilities,  resources  and  schedules  for  test  and  evaluation.  Test  resource 
requirements  must  be  addressed  In  the  TEMP,  along  with  a  critical  analysis  of  any 
shortfalls  that  will  impede  the  full  test  and  evaluation  of  the  system.  The  need  for  and  tho 
availability  of  the  various  diagnostic  elements  which  make  up  tho  diagnostic  capability  Is 
addressed  In  the  TEMP.  Plans  to  correct  existing  or  anticipated  test  resource  limitations 
are  also  included,  as  Is  a  listing  of  evaluation  criteria  delineating  critical  parameters 
permitting  continuous  oversight  and  independent  assessment. 

DoD  5000.3-M>1  contains  the  guidelines  for  the  preparation  of  the  TEMP. 
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REQUIREMENT  #6.1 


CHECKLIST 

□f  Hav«  T4eE  aotlvltlet  b««n  raaliitloally  planned  and 
•ehadulad  to  provide  neoded  Information  on  the 
performance  of  the  entire  diagnoetic  eapability? 
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OPER.  CONCEPT  DEM/ 

SYSTEM  REOMTS.  EXPLOR.  VAL 
ACQ.  PHASE  tixr-LUK.  val 


WEAPON 

SYSTEM 

AcnvmEs 


DIAGNOSTIC 

AcnvmES 


PROD/ 

DEPL 


DIAGNOSTICS 

DTdeE 


Evtiuatf  diagnottlot  parformanot  oharaottrlstlei  during  Dtvtloptmtnt  Taat  and 
Evaluation  (DT&E)  aotivltlaa  In  ordar  to  datarmlna  diagnostic  oapabilHIaa  aohlavad  and  to 
Idantify  daflolanclaa  In  tha  diagnoatio  capability.  Diagnostics  DT&E  should  also  attand  to 
tha  capability  aohlavad  by  tha  Intagratlon  of  tha  various  plannad  diagnostic  alamancs 
(parformanoa  monitors,  BIT/SIT,  tasting  (automatic  and  manual),  malntananoa  aids, 
taohnloal  Information  and  training  (skills))  into  a  oomprahansiva,  oohasiva,  diagnostics 
subsystem. 

PRffOSPVM 

Davalopmant  Tast  and  Evaluation  Is  tha  T&E  oonduotad  throughout  various 
phases  of  tha  aoquIsHlon  prooaas  to  anaura  tha  acquisition  and  flalding  of  an  affaotiva  and 
supportable  system  by  assisting  In  tha  anginaaring  design  and  davalopmant  and  verifying 
attainment  of  taohnloal  performance  specifications,  objactivus  and  supportablllty. 

Davalopmant  Tast  and  Evaluation  also  Includes  T&E  of  components, 
subsystems  and  preplanned  product  improvamant  (P^l)  changes,  hardwara-softwara 
Intagratlon  and  related  software,  as  wall  as  qualification  and  production  aooaptanoa 
tasting.  Teat  and  evaluation  of  compatibility  and  Interoperability  with  existing  or  plannad 
equipment  and  systems  Is  emphasized.  Development  Test  and  Evaluation  anoompasaas 
tha  use  of  models,  simulations,  and  tastbads,  as  wall  as  prototypes  or  Full-Scale 
Davalopmant  models  of  the  system. 
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Th*  dMigntr  thould  b«  at  aetlvaly  involvad  In  diaonoatloa  DT&E  to  anaura  that 
valid  taata  ara  davlaad  and  parformad,  valid  raaulta  dooumantad,  and  valid  data 
aooumulatad  and  to  anaura  that  a  oloaad'loop  analytic  approach  la  uaad  to  pinpoint  and 
oorraot  diagnoatio  daficlanelat.  Tha  daaignar  ahould  anaura  that  avary  opportunity  la 
baing  takan  to  avaluata  dlagnoitlos*ralatad  paramatara.  Thia  may  Involva  a  wida  ranga  of 
teat  aotivltlaa.  Including  rallablllty  taata,  parformanoa  taata,  human  factor  taata.  ato. 
Baalcally  whanavar  a  ayatam,  aubayatam  or  oomponant  la  baing  oparatad.  It  la  aubjact  to  a 
fallura.  Tha  diagnoatloa  raquiramanta  aaaoolatad  with  daaling  with  tha  fallura  ahould  ba 
vlawad  aa  an  opportunity  to  aaaaaa  tha  diagnoatio  capability. 

QUIPANfiB 

Tha  thruat  of  tha  Intagratad  Diagnoatloa  Prooaaa  with  raapaot  to  DT&E  la  to 
Inoluda/tnjaot  diagnoatio  parformanoa  avaluatlon  Into  tha  malnatraam  of  DT&E  aotivltlaa. 
ThIa  la  dona  auoh  that  diagnoatio  parformanoa  oan  ba  avaluatad,  daflolanolaa  pinpointad. 
and  oorraotiva  action  Implamantad  whila  tha  ayatam  la  atlll  In  davalopmant. 

Tha  diagnoatloa  OT&E  affort  aaalata  tha  diagnoatio  daaign  and  davalopmant 
prooaaa.  and  varlflaa  attainment  of  diagnoatio  taohnioal  parformanoa  apaolfloatlona, 
raquiramanta,  and  objaotivaa.  Aa  auoh,  H  la  an  Integral  part  of  tha  weapon  ayatam  daaign 
prooaaa.  Through  tha  provlalon  of  diagnoatloa  DT&E  data,  there  la  a  faadbaok  raltarativa 
loop  baoA  Into  tha  Intagratad  diagnoatloa  aotivltlaa  In  prooaaa,  Including  tha  diagnoatio 
ayatam  engineering  analyala;  diagnoatio  riak  analyala;  allocation  of  diagnoatio  goala; 
diagnoatio  tradaa  for  ayatam  optimization;  diagnoatio  daaign  tradaa;  and,  tha  Idantifloatlon 
and  parformanoa  of  diagnoatio  daaign  taaka.  Through  thia  methodology,  tha  diagnoatio 
daaign  la  oorraotad.  Improved,  or  updated,  and  tha  diagnoatio  daaign  maturaa. 

Sufficient  diagnoatloa  DT&E  rnuat  ba  aooompllahad  before  tha  Mllaatona  III 
daclalon  to  proceed  to  production.  Thia  will  anaura  that  tha  major  apaciflad  diagnoatloa 
daaign  and  davalopmant  raquiramanta  for  tha  Full-Scale  Davalopmant  Phaaa  have  bean 
mat,  with  raipaot  to  parformanoa  raquiramanta  and  apaolfloatlona  ountalnad  in  program 
dooumanta. 

Tha  aoopa  of  diagnoatloa  T&E  afiould  Include  fault  dataotlon,  iaolatlon  accuracy 
and  tlmallnaaa  provided  by  parformanoa  monitoring,  BIT/SIT,  automatio  and  manual 
tatting,  technical  Information  and  maintananca  aide,  maintananoa  prooaduraa,  manpower, 
paraonnai  and  skill  lavala  at  tha  ayatam,  aubayatam,  LRU/LPM,  SRU  levels  across 
planned  maintananoa  echelons  (Organizational,  Intarmadinta  and  Depot). 

• 

Any  deviation  from  this  full  scope  of  T&F.  means  that  full  contidanca  cannot  ba 
ascribed  to  the  planned  diagnostic  capability. 

Tha  major  approaohas  ct  DT&E  for  diognostloa  include  actions  : 
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I 


1 


0  To  proofed  In  phase  with  the  syetem  and  support  equipment  development. 
80  that  Built'In  Teat  (BIT)  it  tested  and  evaluated  concurrently  with  system 
performance;  BIT  and  System  Integration  Test  (SIT)  tested  and  evaluated 
concurrently  with  subsyetem  Integration  and  system  testing;  and,  system 
Integration  and  safety  testing  are  concurrent  with  diagnostic  testing  of  BIT 
and  SIT  features. 

0  To  Implement  with  the  Diagnostics  Maturation  Program  so  that  deficiencies, 
ambiguities,  and  additional  failure  modes  Identified  during  DT&E  are 
recorded  In  a  timely  manner  to  ensure  traceability  and  appropriate 
corrections  are  made  to  the  integrated  diagnostic  procedures. 

o  To  evaluate  embedded  diagnostic  design  as  a  separate  entity  In  order  to 
assure  that  It  has  been  Inoorporated  adequately  as  part  of  the  system 
design. 

0  To  evaluate  for  100%  diagnostic  capability  In  selected  orltlosi  areas  of 
system  design  using  fault  evaluation. 

0  To  analyze  the  system  design  hierarohy  of  test  tolerances  (e.g.,  between 
system  BIT  and  LRU  and  SRU*level  BIT)  In  order  to  minimize  false  alarms. 

0  To  complete  feasibility  DT&E  on  prototype  and  preproduotlon  units  in  order 
to  assess  technioal  rlsKs  and  develop  solutions  to  remedy  deflolenoles. 

During  PSD,  specKlo  diagnostio  capability  segments  of  DT&E  efforts  Include  the 
following  requirements; 

0  When  available,  ATE  shall  be  evaluated  for  Initial  uae  aupporting  build  and 
oheok'out  of  syeteme.  Manual  procedures  and  associated  operational 
prototypes  shall  be  developed  for  support  of  test  activities. 

0  Engineering  evaluation  of  the  diagnostio  elements  capability  at  subsystem 
and  syetem  levels  shall  be  conducted  In  concert  with  syetem  Integration 
testing  actlvltlee,  Including  evaluation  tests  in  the  engineering  laboratory  and 
system  Integration  test  faoilitiee. 

0  Effective  development  of  a  diagnostic  capability  requires  that  testing  of 
diagnostic  capabilities  proceed  concurrently  with  prime  and  support 
equipment  development  In  an  orderly  and  planned  tlme>phaeed  manner. 
The  object  of  the  following  diagnostics  testing  approach  is  to  provide  a  viable 
Organizational-  and  Intermediate-level  diagnostio  capability  for  use  In 
support  of  flight  and  operational  testing  activities  to  provide  for  early 
maturation  of  the  diagnostic  capability.  It  should  also  be  a  program  objeotive 
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to  valldatt  tht  diagnootio  oapablilty,  «•  woll  at  initial  raliabllity  and 
maintainability  raquiramanta  btfora  produotion. 

0  During  tarly  aquipmant  davalopmant  taata.  built>in  tatt  faaturat  should  ba 
tattad  and  avaluatad  ooneurrantiy  with  aquipmant  parformanoa  tatting.  BIT 
parformanoa  la  Just  at  attantlal  to  ovarall  waapon  tyatam  parformanoa  aa 
tha  usually  amphatizad  atpaott  of  aquipmant  parformanoa.  SImulatad 
aquipmant  failurat  should  ba  utad  to  assist  In  BIT  tasting  and  avaluatlon. 

0  As  aquipmant  prograssaa  to  subsystam  Intagratlon  and  parfomnanoa  tasting, 
BIT  and  Systam  Intagratad  Tast  (SIT)  taaturas  should  ba  oonourrantly 
tastad,  avaluatad.  and  oorraotad.  SImulatad  or  amulatad  aquipmant  failuras 
should  again  ba  usad  for  BIT/SIT  taating  and  avaluatlon. 

0  Syatam  Intagratlon  and  safa>for-flight  tasting  of  aquipmant  should  inoluda 
dlagnostlo  tasting  of  BIT  and  SIT  faaturat  to  assura  raadinass  of  this 
capability  for  Right  Tast  Support.  Conourrantiy,  Organlzatlonal*laval  support 
aquipmant  raquirad  for  dlagnostlo  support  should  ba  tastad  to  anabla  Its  usa 
in  tha  tatt  program,  togathar  with  Prallmlnary  Maintananoa  Manuals  for 
Initial  Oparational  Tast  and  Evaluation.  SImulatlor  of  aquipmant  failuras  to 
avaluata  diagnostic  oapabllltiat  should  ba  Includad  In  this  tasting  effort. 

0  Qualification  tasting  of  both  prima  and  support  aquipmant  shall  Inoluda 
validation  of  diagnostic  oapabllity.  which  It  a  raquirad  aspect  of  both 
aquipmant  and  system  parformanoa.  Simulated  aquipmant  failures  should 
ba  Included  In  tha  diagnostic  validation  test  program.  Evaluation  of  BIT/SIT 
should  also  ba  conducted  during  environmental  extrema  tasting  of  tha  prime 
aquipmant  and  support  aquipmant,  to  assura  Its  proper  functioning 
throughout  tha  raquirad  aquipmant  parformanoa  anvalopa. 
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CHECKUST 

S/  Doos  the  Integrated  Test  Plan  provide  adequate 

detail  coneernina  specific  T6eE  procedures,  data  bases, 
models,  test  articles  ond  scope  of  testing? 

S/  Hove  critical  or  high  risk  Items  related  to  diagnostic 
eopoblllV  been  Identified  and  highlighted? 

of  Are  the  necessary  test  articles  ovolloble  to 
conduct  realistic,  timely  tests? 

63f  Has  every  opportunity  to  evaluate  diagnostics  during 
DTdeE  aetivltree  been  Identified? 
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WEAPON 
SYSTEM 
ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

PSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTMTIES 

A  A 

IOT*E  FOT4te 

DIAGNOSTIC 

AcnvrriES 

A  A 

DIAGNOSTICS 

OTkl 

piAfltt^&Agnygi 

Dltgnottlo  ptrformanot  oharaottrlttlos  muat  ba  avaluatad  In  a  raallatio 
oparatlonal  anvironmant  during  OparatlontI  Taat  and  Evaluation  (OT6E)  aotlvHlat  In  ordar 
to  datarmlna  diagnostic  oapabllHIas  aohlavad  and  to  Idantify  daflolanolas  In  tha  diagnostic 
capability.  Diagnostics  OT&E  should  focus  on  tha  capability  achlavad  by  tha  Intagration  of 
tha  various  plannad  diagnostic  alamants  Into  a  comprahansiva,  cohasiva  diagnostics 
subsystem. 

PWOCIPUWB 

Oparatlonal  Tast  and  Evaluation  (OTAE)  Is  tha  flald  tast,  under  realistic 
conditions,  for  tha  purpose  of  determining  tha  affactivanass  and  suitability  of  tha  system  or 
equipment  for  use  In  combat  by  typical  military  users;  and  tha  evaluation  of  tha  results  of 
such  tests. 

Oparatlonal  Tast  and  Evaluation  (OT&E)  activities  include  Initial  OTAE  (lOTAE) 
and  Follow*on  OTAE  (FOTAE).  Tha  results  of  DTAE  aotlvKIas  should  ba  analysed  by  tha 
Contractor  Program  Manager  with  help  from  tha  designer  to  ensure  consistency  and 
continuity  of  TAE  aotivltlaa.  Operational  Tast  and  Evaluation  (OTAE)  must  ba 
accomplished  by  a  separata  government  facility  prior  to  tha  Milestone  III  decision. 
Diagnostics  OTAE  Is  performed  to  provide  a  valid  estimate  of  tha  oparatlonal  affactivanass 
and  suitability  of  tha  systam'a  Integrated  diagnostics  design  and  procedures  using  tast 
Items  sufficiently  representative  of  the  expected  production  Kerns. 
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M«)or  •pprotohM  to  diagnostics  OT&E  Inoluds: 

0  Tasting  in  sn  anvlronmant  ss  oparationslly  raallstio  at  potsibla 

0  OTAE  Initlstod  ss  tarty  ss  poaalbit  during  tha  PSD  Phssa 

0  Tasting  for  adharanoa  to  ovarsll  OT&E  objaotlvat,  with  raipaot  to  diagnostics 

0  Continuad  coordination  with  tha  Disgnostica  Maturation  Program 

0  Evaluation  for  1 00%  diagnostic  capability  In  aalaotad  critical  araas 

0  Random  dlagnostioa  tasting  in  nonoritioal  araas 

0  Furthar  analysis  of  fast  tolaranoaa  ralatad  to  tha  systam  hiararohy  and 
ambaddad/axtamal  diagnostic  prooaduras  in  ordar  to  mlnimiza  falsa  alarms. 

Tasting  (particularly  oparational  tasts)  and  data  collaotlon  should  focus  on  tha 
diagnostics  raquirarhanta.  Tasting  and  data  collaotlon  should  also  avaiuata  tha  spaclflad 
paramatars;  namaly,  Idanttfloation  of  crltloal  falluraa.  tha  falsa  alarm  rata,  tha  paroantaga  of 
faults  dataotad  and  isolatad  automatically  or  manually,  assoolatad  rapair  timas,  tha 
unnaoassary  ramoval  rata,  conslstanoy  of  tast  raaults,  and  tha  adaquacy  of  parsonnal 
sKllls  considaring  all  maintananca  Inoidants. 

During  OT&E,  systam  parformanca,  oparational  suitability  and  supportablllty 
factors  ara  avaluatad  In  an  oparationslly  raaliatlo  anvlronmant.  Thara  ara  two  typas  of 
Information  that  can  ba  obtalnad  for  Diagnostics  T&E:  1)  faults  within  tha  systam  and  how 
thosa  faults  wars  Idsntifiad  (diagnosad);  and,  2)  fauKs/daficianolas  within  tha  diagnostic 
capability.  For  tha  lattar,  this  Inoludas  avaluation  of  aaoh  alamant  which  contributes  to  tha 
total  diagnostic  capability,  as  wall  as  tha  capability,  aohlavad  by  Integration  of  tha 
diagnostics  alamants.  Focused,  detailed  T&E  activities  discussed  in  Raquiramant  #  6.2 
should  ba  continued.  Tha  former  type  of  data  can  ba  obtalnad  as  a  result  of  Reliability 
Growth  Tasting.  Tha  following  specific  Information  should  ba  avaluatad  for  aaoh  fault 
occurranca. 

1 .  How  did  the  failure  manifast  Hsalf? 

2.  Was  tha  manifestation  due  to  stressing  of  tha  systam  beyond  normal 
operational  limits? 

3.  If  a  BIT  alarm  occurred,  was  it  tha  result  of  a  confirmed  failure? 

4.  What  techniques  wars  used  to  Isolate  tha  fault? 
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5.  How  long  did  fault  Isolation  taka  using  those  techniques? 

6.  Was  the  failure  mission  or  operation  critical? 

7.  Was  It  a  now  or  unplanned  failure  mode?  Was  BIT  supposed  to  detect  the 
failure?  Did  It? 

8.  Is  this  failure  mode  expected  to  be  encountered  in  the  operational  system? 

9.  Should  provisions  be  Included  in  the  diagnostic  capability  to  deal  with  this 
failure  mode? 

10.  Will  this  Involve  a  modifloation/addltlon  to  BIT?  ATE?  Manual  Test 
Equipment?  Maintenance  Procedures?  Skill  Levels?  Technical  Data? 
Maintenance  Aids? 

11.  Is  an  ECP  required? 

1 2.  Is  further  Investigation  required? 

If  yes  •  What  plana  have  been  made? 

If  no  •  Why  not?  (brief  description) 

13.  Is  correction  of  the  diagnostic  deficiency  part  of  contractual  requirements? 
Tied  to  Incentive  or  wan'enty  provisions? 


I 
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MATURATION 


REQUIREMENT  #7 


MATURATION  OF  THB  DIACIN08TIC  CAPABILITY 


OVBRVIBW 

HIstorloslly,  oftan  •  weapon  aystam'a  dtagnoatlo 
capability  doaa  not  matt  Its  parformanca 
raquiramants  prior  to  daployment.  Tha  basic 
reason  for  this  Is  that  all  faults  cannot  be  pradlctad 
and,  thus,  adjustment  of  tha  diagnoetio  capability 
Is  required  during  tha  first  few  years  after 
deployment.  Eacentlally,  thia  requires  a  well* 
planned  maturation  period,  which  allows  for  the 
growth  of  the  diagnostic  capability.  Closely 
coupled  with  this  maturation  Is  the  requirement  for 
collection  and  analysis  of  data  relating  to  the 
performance  of  this  diagnostic  capability,  both  in 
the  field  and  in  the  factory.  Care  must  be 
exercised  by  both  the  government  and  the 
contractor  to  assure  that  proper  and  detailed  data 
Is  collected.  Early  planning  for  this  maturation 
period  Is  a  must. 


TESTABILITY/ 

DIAGNOSTICS 


PROGRAMMATIC 


REQUIREMENTS 


DESIGN 


ASSESSMENT 


REVIEWS 


EVALUATION 


MATURATION 


BigOOL 

7.1  A  detailed  DIagnoetIce  Maturation  Plan  needs  to  be  prepared  early  In  the 
acquisition  proeeaa. 

7.2  A  diagnoetio  data  oolleotlon  and  analysis  systenn  muat  be  wstabllshed  to 
provide  for  eorreetlve  nuMsuree. 


MATURATION  PLANNINO 


REQUIREMENT  §7 A 


WEAPON 
SYSTEM 
ACQ.  PHASE 


WEAPON 

SYSTEM 

ACTIVITIES 


DIAGNOSTIC 

ACTIVITIES 


CONCEPT 

DEM/ 

EXPLOR. 

VAL 

SYSTEM  PDR 
SPEC. 


A 

PLAN  UPDATE 


PROD/ 

DEPLl 


PIAGNQgTIOAOnm 

Molt  ditgnoitio  Impltmontitloni,  no  muttor  how  wtll  eonot Ivod,  roquiro  • 
porlod  of  timi  for  Idontlfloitlon  of  problomi  tnd  oorrootlvt  action  to  raaoh  tpeoitiad 
padormanof  lavali.  Thii  rtqulra mint  li  aatabllihad  In  order  to  formallxa  the  dlagnoatloi 
maturation  and  to  allow  the  maturation  to  ba  Initiated  early  In  the  tait  and  evaluation 
prooaia.  Thli  requirement  la  Initiated  early  ao  that  early  Identification,  tracking,  and 
correction  of  diagnoitio  problemi  are  achieved.  The  planning  for  thli  activity  it  formalized 
by  the  development  of  a  Diagnoetic  Maturation  Plan  or  other  appropriate  document. 

PROCroUHB 

While  it  la  the  Contractor  Program  Managera  reepdnalblllty  to  prepare  the 
DIagnoatIo  Maturation  Plan,  the  dealgner  ahouid  underatand  the  eoope  and  methoda  to  be 
uaed  In  maturing  the  diagnoetic  capability  to  aaaure  adequate  corrective  actlona  are 
planned  and  Implemented. 

The  Contractor  Program  Manager  muat  eniure  that  the  plan  la: 

1.  Comprehenaive 

0  Aoroaa  all  diagnoetic  elementa 
0  (noludea  the  Integration  of  the  elementa 

2.  Timely 
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0  le  Initiattd  sarly  to  plan  for  the  raquirad  resourcas  and  Implamant 
eonractiva  actions 

0  Maturation  la  complatad  by  Mllastona  IV,  par  DoD-ln8tructlon*5000.2 

3.  Coordlnatad 

0  Includaa  coordlnatad  aotivltiaa  from  tha  *illtlaa* 

0  Utillzaa  standard  data  eollactlon  systama 

4.  Coat  Effactiva 

o  Allows  data  eollactlon  to  ba  tranafarabla  and  uaabla  by  govarnmant  (l.a., 
DT&E  and  production  tast  data). 


QUIPANCE 

A  program  to  matura  tha  diagnostic  capability  should  ba  plannad  for  tho  aarly 
flaldad  production  systams.  A  ona>to*thraa*yaar  maturation  program  should  ba  plannad 
for  complex  weapon  ayatams  with  axtansiva  automatio  tasting  capability.  For  major 
weapon  systams,  tha  coordination  with  Mllastona  IV,  Logistic  Roadinass  and  Support 
Review  (DoD>lnstruotlon*5000.2)  Is  essential.  This  program  should  Include  provisions  for 
on-sita  collection  of  diagnoatio  performance  data,  with  engineering  follow-up  to  provide 
corrective  actions. 

Tha  plan  should  define  an  approach  and  methodology  to  assure  that  as 
development,  tast  and  evaluation,  and  aarly  operational  use  of  tha  system  progress, 
problems  presented  by  now  failure  modes,  test  voids,  ambiguities,  and  test  tolerance 
difficulties  are  recognized  and  defined,  and  the!  *  solutions  are  traceable  to  diagnostic 
software  and  manual  procedure  updates.  Tha  plan  should  recognize  that  such 
occurrences  are  expected  and  normal  and,  therefore,  should  concentrate  on  problem 
recognition,  definition,  and  correction,  with  appropriate  tracking  tor  traceability. 

The  approach  and  methodology  defined  should  recognize  that  a  basic  elamant 
of  the  Integrated  diagnostics  concept  le  Identification  of  tha  set  of  faults  which  are  known 
or  expected  to  occur.  The  methodology  shall  provide  for  definition  of  this  se’.,  initially 
through  Failure  Modes  and  Effects  Analysis,  Testability  Analysis,  and  other  iouls  and 
experience.  Provision  for  growth  of  this  set,  as  new  failure  modes  are  encountered  during 
testing  and  deployment,  should  be  Incorporated  in  the  plan,  together  with  explicit  crlretia 
to  be  used  In  deciding  whether  or  not  a  newly  encountered  fault  shall  be  added  to  the  set 
of  faults  for  which  explicit  diagnostic  procedures  (as  opposed  to  more  general 
ptoceduras)  are  provided  for  detection  and  Isolation  of  tho  fault.  The  life  cy^le  cost 
effectiveness  of  adding  explicit  diagnostic  procedures  for  the  newly  encountered  fault 
shall  be  one  factor  considered  In  the  decision. 
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The  plan  should  provide  for  an  orderly  development  and  maturation  process  for 
diagnostic  software  and  manual  procedures  throughout  the  development,  test  and 
evaluation,  and  early  operational  use  time  periods  of  the  weapon  system  and  Its 
subsystems.  Methodology  to  assure  timely  and  continuing  technical  support  for  this 
maturation  process  by  both  contractor  and  government  activities,  with  a  minimum  of 
administrative  delays,  should  be  a  feature  of  the  plan.  Orderly  transition  of  technical 
responsibilities  from  the  contractor  to  the  government  should  also  be  addressed. 

The  plan  should  present  milestones  to  be  met.  This  will  assure  that  the  final 
system  achieves  the  required  degree  of  diagnostic  capability.  The  plan  shall  show  the 
time  phasing  of  each  task  and  Its  interrelationship  with  other  tasks.  It  should  identify 
required  data  review,  verification,  and  utilization  to  accomplish  the  required  tasks  and  to 
report  progress,  problems,  and  tradeoffs.  The  plan  should  assure  the  proper 
Implementation  of  diagnostic  design  features  by  designers  and  subcontractors. 

During  the  Dem/Val  Phase,  maturation  planning,  is  centered  on  preliminary 
planning  for  data  collection,  analysis  and  coordination  with  similar  requirements  for 
reliability,  maintainability,  logistics,  data  collection,  analysis  systems,  etc.  Specifically,  this 
planning  should  Identify  potential  data  sources,  such  as; 

0  Laboratory  testing 
0  Oeveloprnental  testing 
0  C^reratlonal  tsst  and  evaluation 
0  Acceptance  testing 
0  Preproduction  testing 
0  Production  testing 
0  Operation. 
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CHECKLIST 

E2f  Dom  th«  Diagnostict  Maturation  Plan  Includt  a  stratogy 
for  the  collection  of  diagnoetic  performance  data 
through  DT^E.  OT&E.  Production,  Initial  Operational 
Use.  and  Deployment? 

E/  le  the  diagnoetic  data  collection  plan  In  eufficlent 
depth  to  allow  adequate  evaluation  of  diagneotic 
eapabilliy? 

^  Doee  the  plan  Include  provtetone  for  all  diagnoetic 
elemente  — >  embedded  ond  e^dernal  — 
ae  well  ae  the  Integration  of  the  diagnoetic  elemente? 

EST  It  the  Integration  the  diagnoetic  elemente  planned 
for  early  enough  to  allow  evaluation  and  coet-effecttye 
correctF/e  action  (e.g.,  prior  to  production  go-ahead)? 

E/  Doee  Maturation  Planning  Include  provlelone  for  both: 

1.  Adequacy  of  the  diagnoetic  elemente,  with  reepect 
to  the  epecified  allocated  capobllity,  and 

2.  Unplanned  failure  modee,  which  mqy  arlee  throughout 
OTdcE,  DTdeE,  Production  Teet,  and  Field  Uee  Teet? 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

Acnvmr 

zs  zs  zs 

SYSTEM  PRODUCT  ECP 

FABRICATION  BASEUNE 

DIAGNOSTIC 

ACTMTIES 

A  A  A  A  A 

DTItE  lOTItE  wrai  DATA  OOP- 

OOL>  MDOTMC 

UOnON  ABTION 

Data  ralating  to  tha  parformanoa  and  a ffaotivanass  of  tha  diagnoatio  oapablllty 
must  ba  oollaotad  during  davalopmant,  production,  and  oparatlon.  This  data  Is  usad  as 
tha  basis  for  tha  avaluation  of  diagnostics  and  for  tha  oorraotlon  of  daflolanolas. 

Tha  Kay  thrust  of  this  activity  Is  dafinitlon  of  approprtata  data  to  ba  oollaotad, 
maximum  usa  of  data  oollaotad,  ooordinatlon  of  data  collactlon  systatns,  and  a  struoturad 
approach  to  corraotiva  action. 


Tha  Contractor  Program  Manager  Is  rasponsibla  for  tha  Implamantatlon  of 
diagnoatio  data  collactlon  and  faadback  raquiramants.  This  Includes  davalopmant  and 
Implamantatlon  of  a  oradla*to«grava  system  for  both  contractor  and  govammant  uaa.  It  Is 
tha  dasigrnr's  job  to  maKa  auia  thaaa  daslgn  oorraotlons  are  Implamantad. 

Tha  aarliar  diagnoatio  parformanoa  daflolanolas  ara  Idantiflad,  tha  soonar  a 
more  ooat*affaotlva  solution  oan  ba  Implamantad.  Tharafora,  diagnostic  data  oollaotlon 
and  faadback  Is  Initiated  early  In  tha  test  and  avaluation  process,  continues  through 
production  test,  and  extends  Into  the  operational  environment.  Throughout  these  phases, 
different  types  of  data  ara  collaotad,  different  data  collactlon  procedures  and 
mathodologlas  ara  used,  and  different  types  of  analysis  technique  are  conducted. 
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QUIPANCE 

Th«rt  art  no  atandard  nr.athodt  for  data  oollootlon  and  anatyals.  At  Indloatad 
undar  Raquiramant  #7,1,  Maturation  Planning,  tha  oollaotlon  of  thia  typa  of  data  la 
controtiad  by  a  numbar  of  military  atandarda.  Tha  raquiramanta  for  tha  atandarda  which 
daal  with  loglatloa,  raliability.  maintainability,  taalability,  human  anginaaring,  and  aafaty 
ovarlap  ona  anothar  (many  timaa  data  raquirad  by  ona  may,  indaad,  ba  raquirad  by  tha 
othar(a)).  Thua  olota  coordination  among  thaaa  varloua  data  raquiramanta  la  naadad.  A 
aingla  data  baaa  la  daalrabla.  Soma  toola  ara  availabla  to  aaalat  In  tha  faadback  and 
analyala  taak.  Thaaa  daaoriptlona  ara  containad  In  Appandix  C. 

Tha  data  oollaotlon  prooaduraa  oioaaly  follow  tha  taat  and  avaluatlon  funetiona. 
Aa  axplainad  In  DoD  DIraotIva  5000.3,  Taat  and  Evaluation,  tha  tima  parioda  and 
taquanoaa  for  Davalopmant  Taat  and  Evaluation  and  Oparatlonal  Taat  and  Evaluation 
vary  from  program-to^rogram.  Thay  can  ovarlap  and  avan  ba  dona  aa  a  oombinad  taat 
and  avaluatlon.  Thua  thara  ara  no  atandard  guidallnaa  that  apaoNy  tha  axaot  pointa  in  tha 
waaoon  ayatam  aoquialtlon  phaaa  whara  data  la  to  ba  ooiiaotad.  Tha  ayatam  muat  ba 
flaxibla  to  Inoorporata  data  aa  data  la  ganaratad. 

Tha  Contractor  Program  Manager  ahould  anaura  that  tha  proper  data  la 
ooiiaotad  and  that  oorraotiva  aotiona  ara  purauad.  It  la  tha  Job  of  tha  daaignar  to  make 
thaaa  oorraotlona.  Cara  muat  ba  taken  to  oollaot  only  that  data  required  to  aaaura  that 
tha  diagnoatio  oapabllitlaa  ara  performing  aa  raquirad.  Automated  data  oollaotlon  ayatama 
can  ba  employed.  Uaualiy  thaaa  ara  more  affaotiva,  aa  thay  ara  laaa  dependant  on 
human  motivation  to  aupply  tha  raquirad  Information. 

Conactlva  analyala  and  aotiona  ahould  ba  In  a  oloaad-loop  ayatam,  ao  that  aaoh 
daflolanoy  Identified  ramaina  an  open  item  until  It  la  formally  dooumantad  aa  being 
oorractad. 


Tha  data  oollaotlon  and  faadback  ayatam  ahould  bo  daaignad  ao  that  apaolflo 
information  la  ooiiaotad  on  tha  parformanoa  of  tha  entire  diagnoatio  capability,  aa  wall  aa 
for  each  of  tha  diagnoatio  alamanta  that  make  up  tha  diagnoatio  capability.  Tha 
Information  muat  ba  ooiiaotad  In  quantitative  form.  If  poaalbla,  and  related  to  Syatam 
Spaolfioatlon  raquiramanta.  Thua  tha  following  guidallnaa  on  tha  typa  of  data  to  ba 
ooiiaotad  need  to  ba  tailored  ao  that  tha  Information  can  ba  related  to  Syatam 
Specification  raquiramanta  and  ao  that  it  la  clearly  apparent  who  la  to  supply  tha 
Information  and  whan  this  Information  la  to  ba  supplied.  Examples  of  the  typa  of  data  to 
ba  ooiiaotad  follow. 


I 

1 

\ 
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DIagnoatle  Data  Paadbaek 

0  Effactivanais  and  affioianey  of  aach  diagnoatio  alamant 

0  Effaotivanaaa  and  afflolanoy  of  tha  diagnostic  alamants  as  an  Intagratad 

ayatam 

o  Oparatlonal/aupport  Impact  of  tha  diagnoatio  daflolanolaa 
0  Corractlva  actlon(s)  which  should  ba  takan  or  hava  baan  takan. 

BIT  Iffaotivanaaa 

0  Fault  Isolation  tima. 

Traeking  of  Palaa  Alarms 
0  Typa  of  alarm 

0  Fraquanoy  of  alarm  oocurranoa 
0  Cauaa  (If  Known) 

0  Potantlal  oonaaquanoaa  of  ignoring  tha  alarm  (craw  aafaty.  mission 
rallabliny) 

0  Oparatlonal  oosta  of  rasponding  to  falaa  alarms  (abortad  misalons,  dagradad 
mods  oparation,  aystam  down  tima) 

0  Support  costs  aasoolatad  with  ^  falsa  alarm 

o  Oparatlonal  anvironmant  whan  alarm  ooourrad. 

ATI  Iffaotivanaaa  Paadbaok 

0  Workarounds  raquirad  to  ovarcoma  maohanical  or  alactrloal  dafloianoias  In 
tha  UUT/ATE  intarfaoa 

0  Did  tha  ATE  systam  provida  fallura  datactlon  rasuKs  conslstant  with  thosa  of 
initial  fallura  datactlon  by  BIT? 

0  Wara  tha  ATE  tast  rasults  rapaatabla? 

o  Ambiguity  siza 
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0  Fault  Isditlon  tlm«. 

Intagrutlon  of  DIognottIo  BItnwnUi 

0  Art  dlagnottlo  rttourott  providtd  oontitttnt  with  tht  trainlng/tMII  Itvtit  of 
Mtigntd  ptrtonntl? 

0  Efftot  of  ftltt  altrmt  trHl  unntotattry  rtmovtit  on  optrttlonal  •vallablllty 
■nd  mainttnanot  workload 

0  Shop  throughput 

0  Wrong  or  Inadtquatt  ttohnioal  Infonnatlon 
0  Loglatk}  dtlay  timt 
0  BITrtllablllty 
0  ATE  rtllablllty. 


Dlagnoatlo  data  oollaotlon  and  diagnoatio  capability  ptrformanot  aaaaaamant 
may  load  to  tht  rtquirtmtnt  for  oorrtotivt  action.  Corrtotivt  action  may  Involve  rtdttign 
of  prime  equipment,  teat  equipment,  Interface  devloea,  maintenance  documentation.  bullt> 
In  teat  olrouKa,  dlagnoatlo  aoftware,  and  ATE  teat  programa.  All  ohangea  muat  be  made 
under  atrlot  configuration  control. 

The  dealgner  muat  reoognlze  that  modifloatlona  to  the  prime  ayatem/equiprnent 
may  dictate  modifloatlona  to  the  dlagnoatlo  capability  aa  well. 
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CHECKUOT 


It  thtrt  dtrtct  communteotton  back  and  forth  bttwatn 
tht  ptrton  who  rtportt  a  prebitm  and  the  ptrton  who 
will  DO  eorrteting  tht  probitm? 


of  Art  all  failurta  btfng  anaNitd  to  ti 
Idtntliy  fatiurt  cauttt  and  perform 
eorrtetivt  oetlont? 


ltd  to  auffteltnt  dtpth  to 
perform  ntetttary 


7-13 


LESSONS  LEARNED  APPENDIX  A 


T«bl«of  Contonto 

1.0  INTRODUCTION .  3 

2.0  ESTABUSHMEhfT/INTERPRETATION  OF  REQUIREMENTS ...  4 

3.0  STRUCTURING  DESIGN  CONCEPTS/CONSTRAINTS .  7 

4.0  MEANINGFUL  PREDICTION  AND  ASSESSMENT 

METHODOLOGY .  11 

5.0  DESIGN  REVIEWS .  12 

6.0  DEMONSTRATIONS . 13 

7.0  MATURATION .  14 

8.0  SUMMARY .  16 


A-1 


LESSONS  LEARNED 


APPENDIX  A 


1.0  INTRODUCTION  AND  BACKGROUND 

Tht  d«tign  0ngln««r  it  th*  K«y  to  solving  ono  of  tht  most  oorplsx  probltmi^ 
facing  tht  military  strvlots  In  ytars.  Tht  probitm  Is  that  today's  wc^tpor  systtms  havt 
btoomt  to  sophlstioatad  that  tht  capability  to  maintain  and  rtpair  them  Is  a  national 
priority.  No  longer  can  tht  design  engineer  be  primarily  concerned  with  the  equipment 
meeting  the  operational  requirements.  Reliability  and  maintainability  must  be  given  equal 
consideration.  Consideration  can  no  longer  be  given  only  to  varying  environmental 
conditions  under  which  the  fielded  product  must  operate.  Equal  consideration  must  now 
be  given  to  the  conditions  under  which  repairs  will  be  performed.  Seemly  short  and 
simple  tasks  often  become  very  time  consuming  when  accomplished  under  extreme 
temperature  oondKions  or  In  restrictive  clothing  such  as  chemical,  bioiogloal  or  radiological 
attire. 


The  services,  burdened  with  exoeesive  maintenance  problems.  Increasing 
demand  for  skilled  manpower  and  skyrocketing  costs,  have  given  Industry  a  clear 
message.  The  Air  Force,  for  instance,  haa  Implemented  a  program  which  states  basically 
that  all  new  equipment  will  be  designed  to  double  reliability  and  reduce  repair  time  by  half. 
Reliability,  maintenance,  quality,  and  productivity  In  new  equipment  will  be  given  as  much 
attention  as  performance,  program  schedule  and  cost.  The  effects  of  this  new  program 
can  be  seen  In  recent  development  of  a  tow-altitude  navigational  system.  Performance  at 
InHIal  testing  was  wHh  operational  requimmente.  However,  due  to  higher-than-antlolpated 
vibration  level,  reliability  requirements  could  not  be  demonstrated.  The  program  was  not 
permitted  to  continue  to  the  next  phase  until  reliability  reached  the  required  growth 
curvet.  This  created  a  delay  of  approximately  six  months,  placing  the  entire  program  In 
trouble. 


Currently,  diagnostics  design  is  the  major  unknown  In  the  reliability  and 
maintainability  arena.  The  statistics  provided  In  this  guide’s  Introduction  demonstrates  the 
magnitude  of  this  fact.  This  appendix  presents  additional  experiences  and  the  key 
learning  points  derived  from  them. 

To  Introduce  these  lessons,  a  brief  hypothetical  scenario  Is  provided  regarding 
the  start  of  a  work  day  for  on  Air  Force  technician  assigned  to  a  modem  bomber  wing. 
This  case  Is  Intended  to  provide  some  Insight  Into  what  diagnostics  programs  may 
someday  achieve. 

Arriving  at  his  duty  station,  the  technician  enters  his  code  at  a  computer 
terminal  and  Is  provided  a  work  order  for  the  first  task  of  the  day.  The  work  order 
concerns  a  malfunction  which  was  detected  during  a  flight  completed  just  prior  to  his 
arrival  at  work.  A  quick  glance  at  the  work  order  reveals  which  system  failed,  what  time  It 
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ooourrtd,  and  tha  Lint  Rtpiaotabit  Unit  (LRU)  which  It  to  bt  rtplaotd  to  oorri)ot  the 
probitm.  Afttr  a  quick  trip  to  a  supply  point  for  a  ttrvlotablt  LRU,  with  tool  box  and 
ohtcklitt  In  hand,  he  departs  for  the  flight  lint.  The  dtfeotivt  LRU  Is  changed  within 
mlnutei  afttr  hla  arrival  at  work.  A  quick  operational  ohtok,  using  the  checklist  and  on- 
board  test  system,  oonflrme  that  no  other  failures  have  occurred,  and  the  system  Is 
declared  operational. 

Back  at  the  Intermediate  shop,  the  flight  line  portion  of  the  work  order  is  closed 
out.  This  Is  quickly  done,  with  a  minimal  amount  of  Information  Input  Into  the  computer 
terminal  regarding  the  work  accomplished.  The  defective  LRU  Is  placed  on  Its 
corresponding  automatic  test  equipment  (ATE).  Keys  within  the  LRU  provided 
Identification  Information  to  the  computer  contained  within  the  ATE.  Failure  conditions 
and  symptoms  recorded  on-alroraft  at  the  time  of  the  failure  are  also  transferred  to  the 
ATE  computer  via  the  computer  network.  Rapidly  the  ATE  goes  through  a  set  a  tests 
specifloally  tailored  to  the  reported  failure  conditions  and  the  failed  single  component  Is 
Identified.  After  the  failed  component  Is  replaced,  the  LRU  Is  checked  again  with  the  ATE 
to  verify  serviceability.  Following  serviceable  testing,  the  LRU  is  given  a  quality  control 
inspection  and  returned  to  the  supply  point,  where  It  once  again  becomes  a  senrieeable 
asset. 


The  above  scenario  (or  parte  thereof)  has  been  a  goal  of  the  military  services 
for  many  years.  Great  strides  have  been  made  toward  achieving  this  objeotlve,  yet  even 
total  suocess  In  limited  areaa  does  not  lay  Immediately  at  hand. 

The  reasons  that  success  Is  fleeting  are  many.  They  Include  budget 
constraints,  a  relative  lack  of  Impodanoe.  potltloal  considerations,  time,  and  the  complexity 
of  the  taskxjust  to  mention  a  few.  This  appendix  presents  a  few  glimpses  of  activity  on 
recent  programs,  results  obtained,  and  lessons  lesmed. 

The  Informstlon  presented  Is  s  composite  of  experiences  derived  from  B>1B 
and  F-1 1 1  Aircraft,  as  well  as  the  Mlnuteman,  Peacekeeper,  and  Small  ICBM  Strategic 
Missiles.  LSA  examples  from  the  AMRAAM  and  30mm  Qun  PODS  are  also  Included. 

2.0  BBTABUBHMIKT/INTBRPRBTATION  OF  REQUIREM1NT8 

What  Is  specified  In  the  procurement  specification  and  the  oontraotusi 
Statement  of  Work  Is  what  the  government  expects  to  receive.  In  the  ares  of  diagnostics, 
the  government  experience  on  past  programs  has  not  been  the  best.  Diagnostic  systems 
have  proven  to  be  Incomplete,  unable  to  to  teat  to  the  desired  level  or  simply  do  not  as 
advertised.  The  basic  foundation  upon  which  any  success  will  be  directly  dependent  Is 
the  clear  understanding  of  the  actual  requirements. 
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NMd  Stattnwnts  and  Work  itatamanta 

All  of  tha  programs  survayad  In  tha  preparation  of  this  dooumant  aaam  to  have 
an  Item  In  common  dealing  with  thair  diagnostic  raquiramanti.  That  commonality  factor  la 
that  tha  quantitative  diagnostic  requirements  Imposed  are  derived  without  a  great  deal  of 
thought  and  analysis.  Typically  diagnostic  requirements  are  more  what  has  been  Judged 
by  someone  to  be  realistic  values,  rather  than  a  product  of  studies  performed  to 
determine  theae  requirements. 

Do0‘lnstruetlon^6000.2  and  other  related  documents  describe  a  structured 
aoquialtlon  process  beginning  with,  among  other  things,  the  development  of  a  Mlsalon 
Area  Analysis  and  a  Mission-Need  Statement.  Included  In  the  Mission-Need  Statement  la 
a  discussion  of  the  Mission  and  Threat,  Alternative  Concepts,  and  Technology 
Involvement.  Subsequently,  during  the  Concept  Exploration  Phase,  studies  are 
conducted  to  develop  a  System  Concept  Paper  which  more  thoroughly  defines  possible 
alternatives,  and  a  selected  concept.  Many  Items  are  taken  under  ccnslderatlon  during 
this  time  frame  Including  readiness,  maintainability,  manpower  and  training. 

It  Is  this  process  which  generally  drives  the  development  of  the  procurement 
specifications.  These  functions  are  primarily  the  concern  of  Government  Program 
Manager;  however.  Inputs  are  sometimes  requested  from  the  contractor.  Failure  to 
consider  testability  when  providing  theee  Inputs  may  limit  chances  for  successful 
diagnostics  later  In  the  program.  Overall  diagnostics  and  testability.  In  general,  should  be 
given  more  concern  at  this  early  stage  of  development. 

Underetanding  Requiremente 

Determining  the  proper  diagnostic  specifications  necessary  to  meet  the  mission 
need  is  one  thing.  Describing  them  In  such  a  way  that  they  will  bo  Interpreted  properly  la 
another. 


The  following  Is  one  of  the  diagnostic  requirements  Imposed  on  the  B-1 B.  The 
CITS  shall  provide  an  assurance  of  05  percent  to  the  aircrew  that  the  system  performance 
Is  operationally  acceptable  or  that  the  Indicated  failure  Is  valid  during  In-flight  performance 
and  ground  readiness  tests.  The  CITS  shall  provide  fault  Isolation  to  an  LRU  with  a 
certainty  of  at  least  75  percent'In  the  ground  fault  leolatlon  mode.” 

Another  requirement  stated  that  ”false  alarms  could  not  exceed  2  percent*. 
Both  seemingly  good  requirements,  but  two  problems  ensued  In  their  accomplishment. 
First  and  foremost  was  the  problem  in  the  definition  of  the  percent  base.  Percentages  are 
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often  used  in  defining  requlrenr.ente.  But  when  to  used,  It  must  be  stated  ae  a  percent  of 
what.  False  alarms,  as  a  percent  of  the  possible  alarms,  gives  one  result.  False  alarms, 
as  a  percent  of  the  number  of  total  alarms  Indicated,  gives  another.  When  written,  one 
must  assume  that  achievement  based  on  definition  of  the  writer  would  meet  mission 
needs.  In  realKy.  when  achieved  based  on  legal  or  Implied  definition,  the  results  were  far 
from  those  required  by  the  operational  command. 

A  second  but  In  this  case  a  lessor  problem,  was  a  conflict  between  the 
requirement.  The  first  requirement  above  allows  a  5  percent  false  alarm  rate  (100  minus 
the  96  percent  acouraoy).  The  second  allows  only  2  percent.  Specification  ambiguity 
leads  to  Interpretation  which  'vlll  not  necessarily  end  with  the  desired  result.  The  design 
engineer  can  help  eliminate  these  problems  by  Informing  program  management  when 
speoifloation  ambiguity  Is  first  enoountered. 

Leglatle  Support  Analyala  (L8A)  Process 

The  LSA  Is  not  a  direct  function  of  the  design  engineer,  however  the  process 
can  Influence  many  of  the  design  requirements.  MIL*STD«1S8R*1A  defines  basic 
objectives  which  are  achieved  when  this  standard  Is  applied. 

1.  Cause  supportablllty  requirements  to  be  an  Integral  part  of  system 
requirements  and  design. 

2.  Define  support  requirements  that  are  optimally  related  to  the  design  and 
each  other. 

3.  Define  the  required  support  necessary  during  the  operational  phase 


These  objectives  are  accomplished  by  the  selective  application  of  scientific  and 
engineering  efforts  undertaken  during  the  acquisition  proceas,  as  part  of  system 
engineering,  it  is  an  Iterative  process  of  definition,  synthesis,  trade*off,  test  and 
evaluation.  Many  oases  have  been  found  which  Indicate  that  designers  who  successfully 
Incorporate  the  results  of  these  studies  early  will  have  a  maintainable  system  when 
deployed  In  the  field. 
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3.0  STRUCTURINQ  OB8IQN  CONdSPTS/CONSTRAINTS 
Controlling  va  Constraining  tha  Contractor 

Today's  trend  In  spacifloatlon  and  contractor  diraotlon  Is  to  provide  the 
contractors  with  the  maximum  leeway  In  meeting  top-level  requirements.  The  objective  is 
to  allow  the  contraotor  to  define  alternatives,  select  from  the  alternatives  those  which  can 
best  be  accomplished  and  provide  a  product  which  meets  all  of  the  "real*  requirements. 

Existing  systems  covered  by  this  document  were  all  developed  under  a  more 
structured  specification  approach.  The  previous  sohool  of  thought  was,  generally 
speaking,  that  the  more  things  which  can  be  controlled  by  the  specifications,  the  more 
chance  the  end  product  will  be  as  desired.  Experience  with  that  approach  has  led  to  the 
more  open  trend.  This  Is  because  the  tighter  approach  did  not  allow  the  contractor  to 
make  maximum  use  of  his  many  possible  alternatives. 


The  customer  Is  encouraging  the  design  engineer  to  think  In  terms  outside  the 
realm  of  present  diagnostics  technology.  Diagnostics  technology  In  general  has  not 
developed  to  the  point  of  satisfying  the  customer's  requirements  for  maintaining  complex 
weapon  systems.  An  excellent  example  of  the  type  diagnostics  not  desired  Is 
demonstrated  by  the  built-in  fault  capability  of  a  terrain-following  radar.  One  of  the  line 
replaceable  units  contained  within  this  system  Is  the  computer.  Conveniently  located  In 
the  aircraft  noso  compartment,  this  LRU  contains  the  malfunction  Isolation  switch  and 
malfunction  Indicator  on  It's  front  panel.  The  malfunction  Indicator  has  nonvolatile  flags 
set  during  flight  at  the  occurrence  of  a  malfunction.  These  were  designed  to  serve  as 
functional  aids  for  maintenance  personnel  troubleshooting  the  terrain-  following  radar 
system.  However,  many  of  the  malfunctions  Indicated  are  caused  by  aseoclated 
subsystems  that  provide  stimulus  to  the  computer.  This  situation  has  caused 
unnecessary  maintenance  and  supply  cost,  plus  degraded  operational  readiness.  The 
dttlQnir,ritusi  eMUft_that  tlLdlAanostlQS  will  only  be  Influenced  bv  the  parameter  they 
are_ditlflned  to  montor^TheJiSlthlng  the  QUitomer  needs  Is  a  diagnostic  system  which 
Inert  MM  tht  wgrhlqidt 


The  Maintenance  Concept 


The  Logistic  Support  Analysis  tasks  of  MIL-STD-1388-1 A  which  are  concerned 
with  the  development  of  maintenance  concepts  and  constraints  are  very  Important  for  the 
diagnostic  community.  The  design  engineer  will  benefit  greatly  by  being  Involved  with  the 
L8A  analyst  and  Incorporating  the  results  into  the  basic  design  at  the  earliest  possible 
time.  The  MIL-STD-1388  tasks  are  structured  to  ensure  consideration  of  existing 
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resouroas,  compatibility  with  deployment  and  operational  requirements,  and  maintenance 
personnel  skill  level. 

The  tie  between  the  diagnostic  method  and  the  maintenance  concept  is 
bidirectional.  They  need  to  be  established  in  unison.  The  maintenance  concept  Is 
developed  based  on  expected  diagnostic  capabilities.  The  diagnostic  design  ultimately 
forces  the  real  maintenance  concept.  The  designer  who  understands  this  concept 
recognizes  the  MIL>STD-1388  process  as  an  aid  to  achieving  the  desired  maintenance 
concept  Is  success  oriented.  A  lesson  well  learned  is  that  when  these  tasks  are  used  for 
historical  purposes,  Instead  of  a  tool  for  the  designer,  the  desired  maintenance  concept  Is 
seldom  achieved. 

Established  Air  Force  maintenance  policies  utilize  system  operation  as  the  final 
determinant  of  the  need  for  maintenance.  If  the  system  Is  functioning  within  tolerance, 
don't  fix  It.  A  unique  situation  has  developed  on  the  B-1B  aircraft.  Due  to  redundancies 
designed  Into  the  systems,  overall  operation  appears  normal,  while  some  specific  parts 
are  not  functioning.  The  diagnoatics  systems  say  the  parts  should  be  replaced.  System 
operation  Indicates  everything  Is  functioning  normally.  To  date,  partially  due  to  the  lack  of 
confidence  In  the  aircraft  diagnostics  and  partially  due  to  establlahed  habits,  these  type 
malfunctions  are  not  being  repaired.  Generally  the  diagnostics  la  believed  fruity  and  no 
maintenance  action  la  taken  until  another  Item  malfunotlons  rendering  the  system 
Inoperative.  This  experience  shows  that  changing  existing  practices  Is  slow.  If  It  Is 
confused  with  the  lack  of  confidence  In  the  diagnostics,  the  change  la  even  more  difficult. 

The  Unit  Under  Test  (UUT)  designer,  ATE  manager,  and  automatic  test 
equipment  designer  are  all  vital  elements  In  determining  what  off*  equipment  testing  Is 
required.  Once  the  option  for  automated  testing  is  confirmed,  the  ATE  designers  must 
convince  the  UiJT  designer  to  Incorporate  "Design  To"  criteria  for  maintainability,  reliability 
and  testability.  Care  must  be  taken  to  define  the  need  for  ATE,  how  the  ATE  Is  to  be 
used,  how  the  UUT  will  be  designed  for  built-in  test  and  Interfacing  abilities.  ATE 
effectiveness  Is  directly  and  Immediately  dependent  upon  this  co-development  with  the 
unit  under  test.  The  following  support  trade-off  factors  must  be  considered  when 
developing  the  UUT  "Design  To*  criteria; 

1.  The  m&i.itenance  concept  and  requirements  imposed  by  the  Repair  Level 
Analysis  of  the  system 

2.  Requirements  of  the  built-in  test  for  the  UUT 

3.  The  effectiveness  of  UUT  functional  partitioning 
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4.  The  ability  to  Ineert  In  the  UUT  teat  points 

5.  Design  limits  on  reliability  and  maintainability. 

Hisxorloally,  probably  the  prime  reason  for  dissatisfaction  with  a  weapon 
system’s  diagnostic  capability  ie  the  unnecessary  removal  of  "good"  Items  when 
conducting  corrective  maintenance.  The  designer  must  be  aware  of  the  causes  for  these 
unnecessary  removals. 

A  field  survey  team  (details  of  the  survey  are  contained  In  RADC-TR*83*2 
"Study  of  the  Causes  of  Unnecessary  Removals  of  Avionic  Equipment”)  visited  12  APB's 
in  1079  to  determine  the  causes  of  this  problem.  When  the  survey  was  completed,  a 
etudy  analyzed  the  data  and  categorized  the  causes.  The  following  major  causes  of 
unnecessary  removals  (URs)  are  listed  along  with  the  percentage  of  all  URs  for  which 
they  are  responsible. 

This  problem  relates  to  bullMn*test  designs  which  provide  incomplete  or 
ambiguous  Information  to  aircrew  and  ground  crew  operators.  Such  inoomplete 
Information  is  the  reason  that  operators  must  "Interpret"  BIT  Indications.  Thus,  there  are 
instances  when  BIT  Indications  are  misinterpreted  and  an  avionic  equipment  Is 
erroneously  reported  as  malfunotloning.  Such  "malfunctions"  are  termed  false  alarms  and 
result  In  a  CND  or  UR  classification.  T>iese  false  alarms  may  either  Indicate  a  malfunction 
in  a  serviceable  equipment  when  there  is  actually  no  malfunction  In  the  system,  or  may 
not  indicate  a  fault  when  one  existe  In  the  equipment. 

Ineffective  SupervIslon^Supoort  ■  26% 

This  problem  Involves  control  of  the  work  habits  of  maintenance  technicians. 
Although  a  lack  of  such  support  may  be  a  result  of  the  current  short  supply  of  middle 
management  personnel,  special  attention  of  supervision  Is  often  necessary  to  maintain 
control  of  the  UR  rate. 

Lack  of  adequate  troubleshooting.  Incorrect  use  of  test  equipment,  improper  or 
inadequate  documentation,  and  lack  of  historical  tracking  of  aircraft  and  LRUs  for 
Intermittent  problems  all  tend  to  point  to  the  lack  of  effective  direct  supervision. 
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M»n«fltnTnt  Dlrtctlvti  ■  1 1% 

This  probitm  relates  to  bypassing  tha  normal  standard  troublashooting 
proctduras  to  obtain  quick  rasponsa  turnaround  tlmas  for  priority  sortias.  Thara  ara  tlmas 
whan  turnaround  tima  Is  most  Important  and  any  supporting  action  Is  justiflad.  Howavar, 
this  typa  of  nonstandard  aotlon  should  ba  undar  ragular  survalllanoa  by  auditing 
parsonnal. 

Tast  Eoulomant  DIffaranoas » 10% 

Tast  aquipmant  diffaranoaa  batwaan  diffarant  lavala  of  maintananoa  wara  notad 
by  tha  aurvay  taam  on  ralativaly  "naw*  aquipmant.  A  laok  of  oommonality  In  tha 
calibration  of  tast  aquipmant  was  also  disoarnad  by  tha  flald  survay  taam  at  ona  rapair 
facility.  At  ona  AFB,  eartain  LRUs  raoalvad  from  tha  rapair  dapot  ara  ratastad  bacausa  of 
tha  laok  of  oommonality  batwaan  Naval  tast  aquipmant  and  da^t  laval  tast  aquipmant. 

Inaffactiva  or  Missing  Tast  Eoutomant  •  9% 

This  inoludas  haavy  or  bulky  tact  aquipmant.  In  most  oasas  Inaffactiva,  haavy 
or  unwialdy  tast  aquipmant  is  tha  sama  as  missing  tast  aquipmant  sinoa  It  Is  not  usad.  In 
this  oasa,  nonstandard  troublashooting  la  amployad. 

Inadaouata  Skill  •  7% 

inadaquata  skill  of  maintananoa  taohniolans  In  tha  usa  of  T.O.s,  tast  aquipmant 
and  troublashooting  prooaduras  ralataa  to  tha  taohniolans’  Inability  to  oomplataly  oopa 
with  tha  ralativaly  high  taohnology  of  alactronie  aquipmant.  This  oausa  of  URs  Is  dua  to 
tha  taohniolan  not  ramambaring  datalls  of  hla  past  training;  ba  it  formal,  on>tha-)ob 
training,  taohnioal  readings  or  Just  familiarization  with  aquipmant  and/or  available 
diognostlo  mathods. 

101S9ti.tll2)iltY 

In  addition  to  tha  above,  tha  problem  of  Inacoassiblllty  cannot  ba  overlooked. 
An  inaccsssiblllty  problem  can  have  a  significant  impact  on  tha  unnacassa^  removal  rata. 
Whan  LRUs  ara  not  readily  aooassibla  dua  to  soma  raetrlotad  location,  tha  removal  of  a 
suspect  LRU  may  require  tha  removal  of  ona  or  more  adjacent  LRUs.  Also,  tha  difficulty 
In  reaching  a  suspect  LRU  may  preclude  an  on*aqulpmant  check,  and  tha  suspect  LRU  Is 
removed  and  sent  to  tha  Naval  shot  for  bench  check. 
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4.0  MEANINQPUL  PREDICTION  AND  ASSESSMENT  METHODOLOQY 

In'prootts  •ssvismant  of  diaonostlos  aohitvomanti  haa,  In  tht  past,  baan  lots 
than  adaquata.  In  fact,  ona  of  tha  most  daflnltiva  and  oftan  rapaatad  B-1 B  lassons  la  tha 
naad  for  an  oparatlonal  parlod  to  matura  tha  diagnostic  dasign.  That  lasaon  la  dasorlbad 
balow  In  paragraph  7.0.  Pradlotlon  and  aaaassmant  taohniquas  hava,  In  tha  past,  fallad  to 
provide  suffloiant  Information  to  unoovar  all  of  tha  Inadaquaolas  and  shortoomings. 
Significant  amphasis  Is  ourrantly  baing  placed  on  testability  analysis,  reliability,  and 
maintainability  assaasmant  tools  under  tha  umbralla  of  Computar>Aldad  Acquisition  and 
Logistic  Support  (CALS).  With  that  amphasis,  ona  should  expect  great  Improvements  In 
aasasamant  taohniquas.  Tha  point  for  tha  dasIgn  engineer  on  this  subject  Is  that  tha 
results  of  thaaa  predictions  and  assaasmants  must  be  Incorporated  Into  tha  dasign  so 
diagnostloa  raquiramants  will  ba  fuHlllad. 

Methodology 

Tha  CALS  Initiative  would  inctuda  diagnostloa  tasting  as  an  Integral  part  of  CAD 
dasign.  Tha  concept  la  that  rules  and  taohniquas  would  ba  astabllahad  in  tha  CAD 
machine.  As  a  specific  Item  la  designed.  It  la  constantly  ohaokad  for  test  access,  bulIMn 
test  capability,  or  whatever  other  rules  that  hava  bean  astabilshad. 

This  concept  works  fine  for  evaluating  tha  diagnostic  oharaotartstlos  of  a  single 
alaotronlo  aasambly.  Evaluation  of  a  weapon  system's  central  test  syatam  Is  another 
question.  For  tha  B-1B,  a  complete  Integration  lab  was  davaiopad  to  test  tha  diagnostics 
software  In  a  functional  environment.  That  process  was  useful,  but  still  under  the  best  of 
lab  conditions  soma  things  could  not  ba  davaiopad  to  tha  optimum  level.  An  excellent 
example  is  tha  philosophy  for  checking  tha  thrust  of  a  jet  angina.  Simulated  lab 
condltiona  equate  more  to  an  aircraft  being  on  the  ground.  Thera  thrust  la  compared  to  a 
rafaranca  schedule  of  gross  thrust  versus  turbine  blade  temperature  at  two  disorata 
operating  points.  These  two  points  are  tha  Intermediate  and  maximum  power  aattings. 
To  develop  an  ln«fllght  thrust  check,  a  rafarenoa  has  to  ba  calculated  to  monitor 
performance  across  tha  eritira  power  range.  This  rafaranca  la  obtained  by  comparing  tha 
anginas  in  synchronization  to  ona  another  In  flight.  This  rafaranca  requirement,  plus 
many  preconditions  necessary  for  calculating  or  examining  thrust,  dictated  actual  flight 
tasting  fer  development  of  a  valid  check. 
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PMdbMk  Stnieturt 

Ttm«  !•  nt«d«d  to  Miurt  that  tha  daaign  banafltt  form  tha  aaaaaamant 
prooaas.  Logically,  ona  doas  not  naad  a  whola  lot  of  axparlanoa  to  undaratand  this. 
Howavar,  it  was  provad  onoa  again  on  tha  B-1B  aircraft  that  oompraatad  aohadulaa  tand 
to  allmlnata  thia  tima.  Conourrant  Full-Soala  Davalopmant  and  Preduotbn  maant  that  tha 
funding  for  atudlaa  and  analyala  ooourrad  ao  lata  that  raaulta  could  not  ba  Implamantad. 
Whan  thia  happana,  managamant  diraotlon  la  naadad;  howavar,  managamant  cannot  taKa 
any  action  unlaaa  tha  problam  la  brought  to  thair  attantlon.  Tha  daaign  anginaar  muat 
notify  managamant  or  tha  magnitude  of  tha  problam  will  Incraaaa  with  tha  paaaaga  of 
tIma. 

Informatlen  Plow 

A  oonoam  often  axpraaaad  by  many  daaign  anginaara  la  tha  delay  In  raoalving 
formal  producta  ganaratad  with  tha  MIL<STD-1388  prooaaa.  Certainly  thia  delay  can 
create  concama.  Who  wanta  to  think  the  daaign  la  atabla  only  to  diaoovar  major  ohangaa 
are  required?  Tha  driving  faotora  often  naoaaaltating  thaaa  ohangaa  are  atudlaa 
performed  for  maintainability  and  taatabllHy.  Tha  daaign  anginaar  who  raalixaa  thia  and 
davatopa  a  cloaa  working  ralatlonahip  with  tha  paraonnal  performing  thaaa  atudlaa  will 
have  fewer  aurprlaaa.  Exparlanoa  haa  taught  many  timaa  that  It  la  much  aaalar  to 
oommunloata  and  Incorporate  ohangaa  during  tha  Initial  daaign  effort.  Trying  to  make 
ohangaa  later  la  axpanalva,  time  oonauming  and  often  produoaa  laaa  than  optimum 
raaulta. 


8.0  DIWONRIVIIWS 

Formal  Daaign  Ravlawa  provide  tha  opportunity  for  tha  contractor  to 
damonatrata  to  tha  cuatomar  tha  praaant  daaign  and  what  future  daaign  afforta  hope  to 
aohlava.  If  tha  contractor  can  damonatrata  that  ha  la  meeting  tha  apaolfloatlona,  tha 
cuatomar  can  aak  no  more.  It  la  tha  role  of  tha  daaign  anginaar  to  aaaura  that  auffiolant 
daaign  haa  bean  performed  prior  to  Daaign  Ravlawa,  which  can  damonatrata  with  a 
degree  of  oonfidanoa,  that  diagnoatio  raqulramanta  are  being  fulfilled. 

Behadullng 

It’a  either  too  early  or  too  lata.  Picking  tha  optimum  time  for  ravlawa  la  vary 
Important.  Ravlawa  naad  to  ba  conducted  after  tha  daaign  la  aufficlantly  defined  to  make 
tha  evaluation  but  before  It  la  too  lata  to  make  daaign  ohangaa.  Tha  daaign  anginaar 
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nttds  to  portlolpato  In  tchodulo  dovtiopmont  to  oniure  that  a  revlawabla  product  li 
availabit  at  tha  aohaduled  tima. 

Tha  only  idantiflad  laaaon  laarnad  from  axparlanoa  Is  that  tha  sohadullng  for 
formal  raviaws  Is  typically  datarmlnad  at  tha  baginning  of  tha  program.  Tha  staga  of  tha 
dasign  for  tha  ravlaw  Is  than  whatavar  it  Is  at  tha  sohadulad  tIma.  This  is  not  naoassarlly 
bad,  baoausa  typically  tha  dasignars  Influanoa  tha  work  sohadula  toward  having  a 
ravlswabla  product  on  tha  astabllshad  sohadula.  Usually,  raviaws  cannot  ba  movad  out 
without  jeopardizing  program  sohadulaa.  Dasignars  must  guard  against  committing  to  a 
sohadula  wHh  goals  that  ara  unraallstlo. 

Ravlaw  Emphaala 

Massages  ara  somatimas  sent  to  dasignars  which  can  ba  misintarpratad. 
Informing  them  where  they  should  place  emphasis.  This  misinterpretation  Is  based  on  tha 
importance  an  Item  is  given  In  tha  raviaws.  if  tha  Qovarnmant  Program  Manager  and  his 
ravlaw  team  place  little  emphasis  on  diagnostics,  dasignars  gat  tha  maasaga  that 
diagnostics  ara  *not  Important."  This  has  often  bean  dona  unintentionally  In  tha  past  by 
quickly  passing  over  tha  subject  In  tha  reviews,  or  otherwise  Indicating  a  minimal  concern. 
Tha  dasign  engineer  must  not  forget  tha  importance  of  diagnostics,  aspaoially  In  cases 
where  tha  Qovarnmant  review  team  has  placed  little  emphasis  on  tha  subject. 

6.0  DIMON8TRATION8 

Demonstrations  ara,  In  general,  another  form  of  a  formal  review.  Thus,  most  of 
tha  points  made  In  tha  previous  saotlon  also  apply  hare. 

Tlmallnaaa 

Tha  opportune  time  for  final  demonstration  of  diagnostics  does  not  exist.  If  a 
purpose  of  tha  demonstration  Is  to  Identify  corraotlva  actions.  Efforts  to  sohadula 
demonstrations  early  enough  to  minimize  tha  impact  of  "failure”  have.  In  tha  past,  rasuHad 
In  tha  simulation  of  too  many  conditions  and  resources.  To  perform  a  oomplata 
diagnostics  demonstration,  all  operational  diagnostics  tools  must  ba  In  place.  This 
Includes  support  equipment  (If  appropriate),  training,  technical  publications,  and  any  other 
applicable  diagnostic  tool.  Attempts  to  simulate  or  work  around  tha  absence  of  these 
operational  Kerns  does  not  provide  for  a  oomplata  demonstration. 
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SImulattd  vt.  Oparatlonal  Conditions 

This  problsm  oan  bo  dsmonttratsd  by  axparlanoa  with  •  raoant  modification 
program  on  tha  F*1 1 1 D  Attack  Radar.  Tha  modilloatlon  was  maJor**malnly  mada  to 
improva  rallabillty  and  maintainability.  Ona  aignifloant  portion  of  tha  modification  was  tha 
rt-work  of  tha  bulH-ln  taat  (BIT)  oapabliltiaa. 

Tha  dasign  job  saamad  to  ba  dona  vary  wall.  Daaign  Ravlawa  wara  paaaad. 
Damonatratlona  of  tha  naw  BIT  parformanoa  in  tha  laboratory  OKoaadad  tha  apaolfloatlona 
and  axpaotatlons.  All  lookad  Ilka  a  job  wail  dona  and  tha  contract  wai  oonaidarad 
complata. 

Tha  problam  was  that  on  tha  aircraft,  in  oparatlonal  conditions,  tha  BIT  doas  not 
do  BO  wail.  Tha  BIT  satvaa  two  functions,  ona  baing  to  adviaa  tha  alroraw  If  tha  salectad 
mods  la  oparatlonal,  tha  othar  aarving  aa  a  diagnoatloa  aid  to  maintananoa  paraonnal. 
Tho  alroraw  function  parforms  wall,  which  Is  not  surprising,  baing  part  of  tha  basic 
oparatlonal  raquiramant.  Howavar,  tha  diagnostics  portion  of  tha  softwara  usad  In  tha 
fault  Isolation  prooass  has  raquirad  axtansiva  ra«work.  At  first  glanca,  ona  Is  lad  to  ballava 
that  tha  slmulatad  and  oparatlonal  conditions  must  dlflar  graatly.  This  baing  tha  ossa, 
how  doas  ona  axplain  that  problama  raportad  during  flald  oparatlona  oan  latar  ba 
damonstratad  undar  laboratory  conditions?  Performing  damonstratlons  with  tha  primary 
objactiva  of  showing  oparatlonal  raquiramanta  ara  baing  fulflllad,  with  diagnostics  givan 
sacondary  oonoarn,  only  delays  finding  problems  In  that  area.  An  Important  point  to 
ramambar  Is  that  diagnostics  must  ba  given  equal  oonsidaratlon  to  oparatlonal 
raquiramanta  and  tha  Demonstration  phase  is  another  chance  to  Identify  and  start 
corraotlng  diagnostic  problems. 

Providing  for  Raaouroaa 

Schadullng/obtainlng  raaourcas  for  tha  demonstration  Is  an  early  function.  This 
raquiramant  has  often  bean  overlooked  or  minimized  In  tha  past.  Dasign  anginaars 
Involved  In  tha  demonstration  prooass  should  ba  fully  aware  of  tha  demonstration 
plan/raquiramants  and  assure  that  required  assata  ara  Inputted  for  Incorporation  In  top- 
laval  planning  documents. 

7.0  MATURATION 

Maturation  Is  a  phase  which  has  bean  Idaritiflad  as  necessary  primarily  during 
development  of  naw  systams/tachnology  for  tha  embedded  and  external  diagnostic 
capability.  Ona  aspeoiaily  critical  area  for  these  systems  Is  tha  Inherent  raquiramant  for 
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tfstlng  und«r  aotual  oparating  conditions.  Maturation  baoomas  necassary  to  raflA^  tast 
mathod/fault  llmita/dlagnoatics  logic  ambaddad  within  tha  diagnostics  software  prdgrams 
that  operate  these  systems.  Tha  predicted  oparating  characteristic  of  tha  various  on> 
board  systems  must  be  compared  to  the  aotual  operating  oharaoterlstloa  of  these  systems 
as  they  Interface  with  other  systems  under  vaiying  environmental  conditions. 

Early  Planning 

One  thing  learned  on  the  B*1B  Is  that  the  design  engineer  must  Keep 
management  Informed  of  the  considerable  time  and  resources  necessary  for  maturation. 
The  original  B-1B  development  plan  was  to  mature  the  dlagnoatlcs  system  (CITS)  on  70 
PSD  flights.  That  would,  It  was  thought,  provide  a  mature  eystem  at  the  time  of  the  first 
deployment  of  the  B-IB  to  an  Air  Force  Main  Operating  Base.  Early  In  the  FulLScale 
'  Development  Phase,  It  became  evident  that  the  plan  would  not  be  sufficient.  A  new  plan 
was  developed  to  use  408  SAC  sorties  over  the  years  1885  and  1986.  The  wing  did  not 
fly  the  required  number  of  sonles  over  that  time  period  and  the  program  was  extended 
through  November  of  1987.  Additional  aircraft  deliveries  and  an  Increase  In  sortie 
generation  rate  produced  a  total  of  1009  sorties  by  the  end  of  that  period.  With  that 
number  of  sorties,  sufficient  data  was  gathered  to  Indicate  an  acceptable  level  of 
performance.  At  this  point.  It  Is  estimated  that  as  a  general  rule,  at  leaat  400  to  500 
sorties  will  be  required  to  mature  an  on*board  test  system  like  the  CITS.  Maturation  time 
Is  difficult  to  estimate  and  ae  learned  on  the  B*1B  changes  will  have  to  be  made  as  the 
process  matures. 

Operatlonel  or  Plight  Teet  Environment 

How  does  one  plan  for  600  sorties  prior  to  production?  Is  a  plan  to  fly  four  PSD 
aircraft  on  the  average  of  once  every  three  calendar  days  for  a  year  reasonable?  la  a 
limited  production  block  appropriate  for  maturation?  These  are  questions  which  the 
design  engineer  must  consider  when  advising  management  of  schedules  early  In  program 
planning. 

Expeiienoe  has  Identified  one  addHIonal  oonslderatlon  to  be  Included  In  making 
these  decisions.  That  consideration  Is  the  Impact  a  partially  working  diagnostics  system 
has  on  the  maintenance  technician.  If  technicians  iose  confidence  In  a  diagnostic  aid, 
they  will  not  use.  Further,  It  Is  hard  to  convince  them  that  the  Item  has  been  Improved  and 
that  now  they  can  have  confidence  In  It.  Many  maintenance  technicians  cn  the  B<1B,  F< 
1 1 1  and  other  systems  who  have  been  exposed  to  Inaccurate  diagnostic  methods  have 
never  been  convlnoed  to  use  an  "Improved”  version.  All  B-1B  operating  bases  have  the 
same  current  version  of  CITS.  Field  data  shows,  however,  that  the  bases  exposed  to  the 
earliest  and  poorest  version  of  CITS  continue  to  have  the  highest  false  alarm  and  cannot 
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dupileat*  malntananoa  rataa.  Thia  ia  dua  to  tha  lack  of  truat  atIM  oarriad  from  tha  aarly 
axparlanoa.  Thua,  It  la  Important  to  accompllah  maturation  away  from  tha  majority  of 
oparatlonal  taohnloiana.  If  poaalbla. 

Implamantlng  Malntananoa  Coneapt 

If  tha  malntananoa  concapt  utilizing  tha  plannad  diagnoatioa  la  aignifloantly 
diffarant  from  that  with  which  tha  aatabllahad  taohnioian  ia  familiar,  apaolal  training  will 
naad  to  providad.  Tha  6*1  B  conflict  batwaan  uaing  CITS  or  ayatam  parformanca  to  rula 
that  a  fallura  haa  oocurrad  waa  diaouaaad  In  paragraph  3.0  of  thIa  appandix.  Tranda  ara 
alao  in  plaoa  today  to  laolata  to  and  raplaoa  modulaa  on  tha  aircraft  rathar  than  tha  larga 
*boxaa"  of  tha  paat.  Utilizing  tha  dlagnoatlo  Indication  produced  during  flight  without 
further  ground  varlfloatlon  la  alao  a  currard  trend.  Bach  of  thaaa  "new”  eonoapta  muat  be 
thoroughly  undaratood  by  tha  taohnloiana,  ao  that  tha  maturation  raauita  ara  oonalatant 
with  tha  plannad  flaldad  malntananoa  oonoapt.  Making  ohangaa  la  never  an  aaay 
prooaaa  and  tha  malntananca  taohnioian  ia  no  exception  to  thia  oonoapt. 

8.0  SUMMARY 

Diagnoatioa  la  not  a  aimpla  matter  and  tha  parfaot  altuation  portrayed  In  tha 
Introduction  haa  yet  to  be  achieved,  inataad  of  tha  failure  being  Idantifiad  to  one  LRU, 
often  tha  ambiguity  group  la  aa  many  aa  four  LRUa.  Tha  ATE  which  can  laolata  tha  fallura 
to  a  aingla  failed  component  would  be  tha  Ideal  aolutlon  but,  more  likely  than  not.  It  will 
only  bo  one  or  aomatimaa  aavaral  Shop  Raplacoabla  Unita  (SRUa)  or  a  particular  group  of 
SRUa.  Tha  atapa  oovarad  hare  ara  only  aoma  of  tha  vary  baalo  onaa  required  to  Inaura 
good  diagnoatioa.  However,  looking  at  many  diffarant  programa,  ona  flnda  even  thaaa 
aimpla  atapa  have  bean  omitted,  or  parhapa  aooompllahad,  at  a  time  too  lata  to  have  tha 
daalrad  raauita.  Tha  raaaona  ara  many:  poor  oommunioatlon  of  naada  or  goala,  time 
frame  raatrlotlona,  money,  and  fallura  to  property  oonaldar  tha  Importance  of  diagnoatioa. 
To  anaura  diagnoatioa.  H  muat  be  addraaaad  at  all  phaaaa  and  be  given  equal  Importance 
to  other  performance  raquiramanta.  If  tha  ayatam  cannot  be  maintained.  It  can  never 
meat  Its  oparatlonal  raquiramanta. 
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CHECKU8T 


GSf  Studies,  anolytss,  and  feedback  take  time.  They  need 
to  be  scheduled  eo  that  their  results  can  influence 
the  design. 

E3f  Test  equipment  deeigners  need  to  have  an  input  regard 
ing  the  design  requirements  of  the  units  to  be  tested. 

of  Proper  prioritise  need  to  be  demonstrated  by  both 
government  and  industry  tf  diagnostics  Is  to  be 
properly  implemented. 

El^  Specifications  muet  be  welt  defined  end  represent 
exactly  what  is  needed. 

ESf  Real  operating  time  Is  required  for  maturation  of 
the  diagnostic  qystem— 'lots  of  it. 
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U8T  OP  ACRONYMS 


ABI 

Avionloi  But  Inttrfaot 

ADA 

Adapllvt  DIagnoitIo  Authoring 

ADS 

AdaptIva  Diagnostic  System 

AFLC 

Air  Forte  Logistics  Command 

ADP 

Automatic  Data  Processing 

AF8C 

Air  Force  Systems  Command 

Al 

ArtHlolal  Intelligence 

AIDA 

Corporation  •  Santa  Clara,  CA 

ALU 

Arlthmetlo  Logic  Unit 

AMC 

Army  Materiel  Command 

AMRAAM 

Advanced  Medium  Range  Alr>to>Alr  Missile 

ASIC 

Applloatlon  Specific  integrated  Circuit 

ASTEP 

Advanced  System  Testability  Analysis  Program 

ATE 

Automatic  Test  Equipment 

ATF 

Advanced  Taotioal  Rghter 

ATQ 

Automatio  Test  Generator 

ATLAS 

Abbreviated  Test  Language  for  All  Systems 

ATPQ 

Automatio  Test  Pattern  Generator 

BCPE 

Biphase  Correlator  Processing  Element 

BDL 

Behavioral  Design  Language 

BILBO 

BulK'In  Logic  Block  Observation 

BIST 

BulH-ln  Self  Test 

BIT 

BulK'In  Test 

BITE 

BulK'In  Test  Equipment 

BLM 

Behavioral  Logic  Model 

BMM 

Bulk  Memory  Module 

C/ATLAS 

Common  Abbreviated  Teet  Language  for  All  Systems 

CAD 

Computer>Alded  Design 

CADAT 

Computer<Alded  Design  &  Test 

CADAT  e 

Computer-Aided  Design  &  Test,  Version  6 

CADBIT 

Computer-Aided  Design  for  Built-In  Test 

CAE 

Computer-Aided  Engineering 

CALS 

Computer-Aided  Acquisition  &  Logistics  Support 

CAMELOT 

Computer-Aided  Measure  for  Logistic  Testability 

CASS 

Consolidated  Autometed  Support  System 

CATS 

Computer-Aided  Test  System 

CDDB 

Common  Diagnostic  Data  Base 

CDL 

Circuit  Description  Language 

CDR 

Critical  Design  Review 
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CDRL 

Contract  Data  Raqulrama nta  Llat 

CEP 

Count  Enable  Parallel 

CEPS 

errs  Expert  Parameter  Syetem 

CET 

Count  Enable  Trickle 

CPE 

Contractor  Furnished  Equipment 

Cl 

Configuration  Iteme 

errs 

Central  Integrated  Test  System 

CLK 

Clock 

CLR 

Clear 

CMC 

errs  Maintenance  Code 

CMOS 

Complementary  Metal  Oxide  Seml*Conduotor 

CML 

Current  Mode  Logie 

CMOS 

Complimentary  Metal  Oxide  Silicon 

CND 

Cannot  Duplicate 

CNO 

Chief  of  Naval  Operations 

COPTR 

Controliabllity*Odsen/abiilty*Predlotabllity  Testability  Report 

CPCI 

Computer  Program  Configuration  Item 

CRC 

Cyclic  Redundancy  Check 

CSC 

Computer  Syetem  Component 

CSCI 

Computer  Software  Configuration  Item 

C80M 

Computer  Syetem  Diagnoetio  Manual 

CSI 

CADAT  Systems  Interface 

CSOM 

Computer  Software  Operator's  Manual 

CTE 

Commercial  Test  Equipment 

CTF 

Controllability  Trenafer  Factor 

CY 

Controllability 

D-L«vtl 

Depot  Level 

DAISY 

Manufacturer  Name  •  Mountain  View,  CA 

DATPQ 

Digital  Automatic  Test  Program  Qenerator 

DBDD 

Data  Base  Design  Document 

DCP 

Decision  Coordinating  Paper 

D«m/V«l 

Demonstration  and  Validation  (Phase) 

DFT 

Design  For  Testability 

DIA 

Defense  Intelligence  Agency 

DIO 

Data  Item  Description 

DIP 

Dual  ln>llne  Package 

OMUX 

DemuKIplexer 

DoD 

Department  of  Defense 

OoD'D 

DoD  Directive 

DoD-INST 

DoD  Instruction 

ONE 

Data  Network  Element 

DT&E 

Development  Test  and  Evaluation 
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DTA  Daisy  TaatabllHy  Analyztr 

EARS  Enginatring  Aootat  Routlna  Sat 

ECL  Emittar  Collaotor  Loglo 

ECC  Error  Conraoting  Coda 

ECL  EmIttarOouplad  Logic 

ECP  Enginaarirtg  Chtnga  Pfopoial 

EDIF  Elactronlo  Daaign  Intarohanga  Format 

EIA  Elaotronloa  Industry  Assoolatlon 

ESU  Elamant  Suparvisor  Unit 

ETE  Elactronlo  Tast  Equipmant 


FA  Falsa  Alarm 

FA  Faadbaek  Analysis 

FCA  Functional  Configuration  Audit 

FO  FauK  Dataotlon 

FEFI  Fraction  of  Erronaous  Fault  Isolation  RasuNs 

FFD  Fraction  of  FauKs  Dataotad 

FFI  Fraction  of  Faults  Isolated 

FI  Fault  Isolatlen 

FIQ  Fault  Isolation  Group 

FIPAO  Failure  IndantHioatlon.  Pravantlon  and  Dataotlon 

FIS  Fault  Isolation  System 

FLEX  Name  <Navy  Su^rt  Cost  Modal) 

FMEA  Failure  Modes  and  Effects  Analysis 

FMECA  Failure  Modes,  Effects  and  Critloallty  Analysis 

FOM  Rgura  of  Merit 

FOT&E  Follow*On  Operational  Test  &  Evaluation 

FPPE  Floating  Point  Prooasaing  Elamant 

FRACAS  Failure  Reporting,  Analysis  and  Corractiva  Action 

FSD  Full'Soala  Davalopmant 

FSM  Firmware  Support  Manual 

FYDP  Five  Year  Dafanaa  Plan 


QFE  Qovammant  Furnished  Equipmant 

QIMADS  Generic  Integrated  Maintenance  Diagnostics 

GM  Global  Memory 

GPETE  General  Purpose  Electronic  Tast  Equipmant 

GSB  Ground  Support  Equipmant 

HDL  Hardware  Description  Language 

HITAP  Hl-Tastablllty  Analysis  Program 

HITS  HlararoNoal  Integrated  Tast  Simulator 
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HSDB 

HIgh'Spaad  Data  Bua 

HW 

Hardwara 

HWCi 

Hardwara  Configuration  itam 

loLtvtl 

Intarmadlata  Laval 

I/O 

Input/Output 

1C 

Intagratad  CIroult 

ICE 

Intagratad  Conoaptual  Environmant 

ICNIA 

Intagratad  Communloationa,  Navigation  & 
Idantifloatlon 

ID 

Intarfaoa  Davloa 

ID 

Intagratad  Dlagnoatioa 

IDD 

Intarfaoa  Daaign  Dooumant 

ID88 

Intagratad  Dlagnoatioa  Bupport  8yatam 

IFTb 

Intarmadlata  Forward  Taat  Equipmant 

IQES 

initial  Graphioa  Exohanga  Bpaoifloation 

IL8 

Intagratad  Loglatio  Bupport 

IL8P 

Intagratad  Loglatio  Bupport  Plan 

IMI8 

Intagratad  Maintananoa  information  Byatam 

I/O 

Inpui/Output 

lOTAE 

Initial  Oparatlonai  Taat  A  Evaluation 

IP8 

Intagratad  Program  Bummary 

IR8T 

Infrarad  Baaroh  and  TraoK 

I8P8 

Inatruotlon  Bat  Prooaaaor  BpaoHloation 

ITO 

Intamatlonal  Taat  Confaranoa 

ITP 

Intagratad  Taat  Plan 

JTAQ 

Joint  Taat  Aotlon  Group 

KQM 

Kay  Qanarator  Modula 

LANA 

Looal  Araa  Natwork  Aooalamtion 

LCC 

Ufa  Cyola  Coat 

LCCATM 
LCC  Family 

LIfa  Cyola  Coat  Analyaia 

of  Modala 

LIfa  Cyola  Coat  Family  of  Modala 

LF8R 

LInaar  FaadbaoK  Bhift  Raglatar 

LCCC 

Laadlaaa  Chip  Carriar 

LDCC 

Laadad  Chip  Carriar 

LED 

Light  Emitting  DIoda 

LF8R 

LInaar  FaadbaoK  Bhift  Raglatar 

LOQMOD 

Loglo  Modaling 

LRM 

Lina  Raplaoaabla  Modula 

PROVIDING  A  COHESIVE  DIAGNOSTIC  DESIGN  PROCESS  REQUIREMENT  #3.1 


GUIDANCE 

The  guidance  provided  In  thia  section  Is  designed  to  permit  maximum  visibility 
Into  the  diagnostic  design  process.  The  designer  must  understand  the  design  process 
flow,  timing,  and  data  requirements  which  must  be  satisfied.  In  addition,  It  Is  Important  to 
recognize  that  current  data  Item  procurement  practices  may  not  always  be  supportive  of 
the  design  activity  In-process  data  needs.  At  times,  the  CDRL  and  associated  DID  do  not 
adequately  refled  these  In-process  needs.  The  high  data  Item  generation/revision  costs 
generally  experienced  are  strong  motivators  for  delaying  data  Item  preparation  to  a  point 
where  the  design  has  stabilized.  Such  motivation  Is  In  direct  conflict  with  the  utilization  of 
the  data  to  make  design  decisions.  A  complete,  detailed  data  submittal  indicating  that  the 
design  Is  flawed  Is  of  little  use  after  the  design  has  been  completed.  The  guidance  that 
follows  has  been  designed  to  provide  the  necessary  Insight  into  the  design  process,  which 
will  assist  the  designer  In  doing  a  better  job. 

Design  Environment 

The  diagnostic  design  environment  Is  an  essential  component  of  the  overall 
diagnostic  design  activity,  which  has  been  established  by  the  contractor  In  response  to 
the  RFP  requirements.  This  environment  encompasses  both  the  Implementation 
methodology  and  the  specialty  coordination  associated  with  the  diagnostic  design 
process.  Evidence  of  these  should  be  apparent  In  the  Interim  products  of  the  design 
effort,  which  are  made  available  to  the  government  program  management  function  (at 
both  Informal  In-process  reviews  and  formal  system-level  design  reviews). 

Diagnostic  design  is  characterized  by  its  Iterative  nature  and  a  high  degree  of 
interdependence  with  the  supportabIHty  engineering  specialties  (I.  e.,  reliability, 
maintainability,  Integrated  logistic  support,  testability,  human  engineering,  and  safety). 
The  allocation  of  diagnostic  resources  must  be  based  on  Inputs  from  these  disciplines. 
Therefore,  the  timing  and  quality  of  data  interchanges  must  be  in  accordance  with  the 
program  plans.  A  breakdown  In  data  availability  and  exchange  can  be  responsible  for 
program  delays  and  shortfalls  In  the  fielded  diagnostic  capability. 

The  data  flow  required  to  develop  the  composite  diagnostic  capability  must  be 
responsive  to  the  diagnostic  mix  established  for  the  specific  system  under  consideration. 
Embedded  diagnostic  features,  such  as  built-in  test  (BIT),  built-in  test  equipment  (BITE), 
system  Integrated  test  (SIT),  performance  monitoring,  status  monitoring,  embedded 
training,  embedded  maintenance  aiding,  adaptive  Al-based  diagnostic  systems,  etc.,  are 
an  Integral  part  of  the  prime  equipment  design.  Therefore,  the  diagnostic  data  flow 
associated  with  these  features  must  be  incremental  and  continue  until  the  detail  prime 
system  Configuration  Item  designs  are  complete.  For  the  external  diagnostic  elements, 
such  a.s  automatic  test  equipment  and  the  associated  test  program  sets,  manual  test 
equipment,  portable  maintenance  aids,  technical  Information  (hard  copy  or  elo  tronic 
delivery),  training,  etc.,  the  diagnostic  data  flows  Into  the  LSA  process  up  to  the  point 
where  the  firm  requirements  for  these  diagnostic  elements  can  be  established.  Once  firm 
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requirements  exist,  the  diagnostic  design  environment  must  facilitate  a  smooth  transfer  of 
data,  which  Is  sufficient  In  terms  of  detail  and  format  to  permit  fabrication  of  the  required 
external  diagnostic  capability. 

Table  5  is  a  listing  of  the  major  military  standards  which  Influence  the  design  of 
the  diagnostic  capability.  Some  of  these  military  standards  are  programmatic  In  nature,  In 
that  they  establish  a  specific  program  and  describe  the  tasks  which  can  be  undertaken. 
The  remainder  of  the  standards  are  process  or  product-oriented.  As  can  be  seen,  these 
standards  Influence  various  aspects  In  the  design  of  the  diagnostic  capability,  starting 
from  establishing  diagnostic  requirements,  through  the  design  and  assessment  of  the 
diagnostic  capability.  There  la  a  sequence  of  tasks  and  procedures  cited  In  these 
standards  which  can  be  applied  to  the  diagnostic  capability.  The  interfaces  and 
relationships  between  these  various  activities  are  complex  and  cannot  be  easily 
diagrammed  to  promote  understanding.  Establishing  diagnostic  requirements  Is 
described  In  Requirement  #2,  and  the  assessment  Is  described  under  Requirement  #4. 
Thus  the  following  guidance  will  address  the  design  of  the  embedded  and  external 
diagnostic  capability. 


Design  Integration 

Figure  4  Is  a  simplified  diagram  of  the  Information  flow  In  the  design  of  the 
diagnostic  capability.  The  design  process  begins  with  a  maintenance  concept  and  design 
data,  such  as  specifications,  block  diagrams,  and  schematics.  Establishing  the  system's 
architecture  Is  the  next  step.  System's  architecture  has  a  major  Impact  on  the  design  of 
the  fielded  diagnostic  capability.  The  concept  of  fault  tolerance  supports  the  maintenance 
concept  by  promoting  graceful  degradation  of  the  system's  performance,  thereby  allowing 
the  maintenance  to  be  performed  at  the  user's  convenience  rather  than  dictated  by  when 
faults  occur.  Design  for  testability  concepts  play  an  important  part  at  this  time. 
Partitioning  especially  Is  closely  tied  to  fault  tolerance,  because  the  performance 
monitoring  capability  must  be  able  to  detect  failed  Items  In  order  that  the  capability  of  the 
system  is  known,  that  necessary  switching  to  alternate  means  Is  facilitated,  and  that 
maintenance  actions  can  be  identified. 

The  Failure  Modes  and  Effects  Criticality  Analysis  (FMECA)  utilizes  the 
system's  architecture  and  design  data  to  determine  the  modes,  causes  and  effects  of  Item 
failures.  This  data  drives  the  maintenance  and  safety  requirements  which  In  turn  help  to 
establish  the  diagnostic  logic,  test  point  selection,  and  test  requirements.  From  this 
Information,  the  diagnostic  capability  is  designed  and  fabricated.  Including  the  testing, 
(bullt-ln  and  external),  technical  Information,  training,  and  personnel  capability.  Obviously 
this  entire  process  Is  Iterative  In  nature  -  a  factor  not  IndloatecUIn  Figure  4. 
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HGURE  4.  DESIGN  INTEGRATION  OF  DIAGNOSTIC  CAPABIUTY 
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Th«  concept  of  vertical  testability  was  introduced  years  ago.  In  essence,  this 
concept  addressed  the  compatibility  of  testing  among  all  levels  of  maintenance,  including 
factory  testing.  The  core  of  this  concept  Is  twofold.  The  first  Is  the  establishment  of  a 
Cone  of  Tolerance  among  these  levels,  and  the  second  deals  with  the  compatibility  of 
environments  under  which  those  tests  are  performed. 

The  Cone  of  Tolerance  concept  is  depicted  In  Figure  5,  in  which  the  testing 
tolerances  are  widened  as  the  unit  Is  tested  closer  to  Its  operational  environment. 


The  compatibility  of  testing  environments  can  be  Implemented  best  through  the 
use  of  common  test  equipment  at  Intermediate,  Depot,  and  Factory  Levels.  This 
commonality  of  test  equipment  and  any  associated  test  programs  is  the  method  for 
Implementing  this  compatibility. 

The  concept  of  vertical  testability  is  key  to  the  Integration  of  the  design  of  the 
diagnostic  capability.  Therefore  additional  guidance  on  vertical  test  methods  Is  contained 
In  Appendix  D.  This  appendix  also  Includes  guidance  on  documenting  the  results  of 
vertical  testability  analysis  to  assure  this  information  will  be  Integral  to  the  diagnostic 
design  process, 

Extension  of  this  vertical  testability  concept  Is  recommended  for  the  entire 
fielded  diagnostic  capability.  Figure  6  depicts  this  concept.  In  which  vertical  testing  Is 
shown  on  the  left  and  is  joined  by  technical  Information  and  personnel  and  training 
compatibility  requirements.  Not  only  Is  this  compatiblilty  required  vertically,  but  also 
horizontally.  All  elements  that  make  up  the  diagnostic  capability  must  be  compatible  at 
each  maintenance  level. 

This  concept  of  vertical  and  horizontal  compatibility  Is  Key  to  the  Integration  of 
diagnostic  capability.  The  entire  process  is  driven  by  the  diagnostic  logic  which  effects 
the  requirements  for  all  of  the  diagnostic  elements.  This  diagnostic  logic  can  be 
established  by  a  variety  of  means  Including  the  use  of  maintenance  dependency  charts, 
fault  trees,  etc.  To  Implement  this  concept,  a  series  of  matrices  similar  In  format  to  Figure 
6  can  be  prepared  at  various  system  hierarchy  levels  (e.g.,  system,  subsystem,  LRU, 
SRU).  These  matrices  should  be  tailored  to  the  unique  requirements  of  a  specific  weapon 
system  and  may  be  used  in  conjunction  with  other  required  data  deliverables  (e.g.,  test 
requirements  document). 
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nOUM  0.  DMign  Intagritlon  of  Oiagnootio  Copablllty 
AUTOMATION  OP  THI  DIAGNOSTIC  DIStON  PN0C188 

Automation  of  tha  diagnottio  datign  pro  aaa  It  aneouragad  to  provida  a  mora 
afflolant  and  aftaotiva  daaign  prooaat.  Tha  di<'  jnoatio  datign  prooatt  should  ba  an 
Intagral  part  of  prima  ayttam  oomputar'tldad  anginaaiing  and  datign. 

Tha  addad  afflolanoy  and  affaotivanata  In  tha  uta  of  automation  la  raflaotad  In  a 
numbar  of  wayt.  Tha  affaot  of  changaa  In  althar  tha  diagnostic  datign  or  tha  prima 
ayttam  datign  can  ba  raadily  aacartalnad  a«  tha  datign  prograstas.  Thia  Itarativa 
prooatt  than  can  giva  tha  datignar  Information  on  whathar  or  not  tha  diagnostic 
spaolflcatlon  raqulramantt  will  ba  mat.  In  addition,  automation  permits  tha  concurrent 
davalopmant  and  evaluation  of  tha  entire  diagnostic  capability  along  with  tha  remainder  of 
tha  prime  ayttam. 
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Diagnostic  Dtaign  Tools 

Diagnostic  design  tools  snhanos  the  effectiveness  and  efficiency  of  the 
process;  A  description  of  available  tools  and  processes  is  available  in  Appendix  C. 
Appendix  C  Identifies  automated  tools  which  can  assist  the  designer  in  performing  three 
major  facets  of  the  design  process;  system  architecture  design,  Implementation  of  design 
rules  and  practices,  and  diagnostic  authoring. 

The  first  element  pertains  to  design  automation  tools  that  assist  the  designer  in 
synthesizing  a  prime  system  functional  capability,  as  well  as  providing  an  "environment" 
for  developing  a  diagnostic  capability  concurrently  with  the  prime  weapon  system 
development  process.  The  architectural  tools  not  only  provide  a  capability  to  synthesize  a 
functional  capability,  but  also  assist  the  designer  In  understanding  systems  methods  of 
doing  design  work  (I.e.,  operation). These  tools  generate  documentation  data  bases, 
which  are  either  explicitly  or  Implicitly  usable  In  the  testing,  technical  Information  and/or 
personnel  training  disciplines. 

The  second  element  pertains  to  automated  or  manual  tools  whicn  "capture" 
expert  knowledge  bases  in  dlagnostlc->related  matrices  for  use  by  the  designer.  These 
knowledge  bases  may  range  from  highly  sophisticated  and  automated  expert  system 
software  to  unautomated,  rudimentary  chackllsts. 

The  final  element  pertains  to  tools  and/or  techniques  which  enable  the  designer 
to  "author"  (I.e.,  generate)  diagnostic  software  routines  and  procedures  utilizing  prime 
system  design  data  bases  or  heuristic  Information  sources.  These  diagnostic  authoring 
tools  typically  take  the  form  of  either  expert  system  "knowledge  bridges,”  which  facilitate 
the  extraction  and/or  generation  of  diagnostic-related  procedures;  or  automatic  test 
generators/fault  simulators,  which  generate  digital  test  vectors  to  fault  deteot/fault  Isolate 
an  explicitly  defined  fault  universe  (i.e.,  stuck  ”1  "/stuck  ”0”).  In  addition,  time-tested 
analog  and  mixed  mode  simulators  may  be  utilized  not  only  as  functional  design  tools,  but 
also  as  diagnostic  authoring  tools  In  deriving  and  analyzing  diagnostic  test  tolerances 
utilizing  worst  case  or  Monte  Carlo  analysis  techniques. 
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REQUIREMENT  #3.1 


CHECKLIST 

Has  a  concertad  effort  bean  made  to  assure  vertical 
and  horizontol  Integration  and  compatibility  of 
all  elements  which  comprise  the  diagnostic  capability? 
Has  this  been  documented  for  review? 

Have  steps  been  taken  to  utilize  automation  of  the 
diognostic  design  process  to  enhance  design  efficiency 
ana  to  Improve  the  effectiveness  of  the  fielded 
diagnostic  capoblllW?  Hove  available  design  tools 
been  utilized? 
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WEAPON 
SYSTEM 
ACQ.  PHASE 

OPER. 

REQlyTTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTMTY 

zx  zs  zs  zs 

SYSTEM  SYS.  PREL  DETAIL 

ANALYSES  SPEC.  DESIGN  DESIGN 

DIAGNOSTIC 

ACTIVITIES 

DIAGNOSTIC  DESIGN  ^ 

DIAGNOSTIC  ACTIVITY 

Dtsign  of  th«  diagnostic  capability  and  the  elomants  that  make  up  this 
capability  are  Initiated  early  In  weapon  system  development.  It  begins  soon  after  Initial 
analyses  and  allocation  are  completed  and  extends  at  least  until  Full-Scale  Development 
has  been  completed.  Design  criteria  and  guidance  need  to  be  available  tor  use  as  the 
diagnostic  capability  design  progresses.  Obviously,  the  bulk  of  this  design  guidance  is 
utilized  by  the  designer  of  the  prime  system  and  Its  support  capability.  He  needs  to  be 
totally  familiar  with  guidance  that  Is  available  and  be  able  to  apply  It  appropriately. 

Design  criteria  and  guidance  relating  to  the  diagnostic  capability  and  Individual 
diagnostic  elements  are  available  from  a  number  of  sources,  Including  standards, 
handbooks,  and  guides.  Most  often,  this  guidance  Is  not  a  contractual  requirement, 
except  when  a  specific  military  standard  Is  Invoked.  However,  for  the  most  part,  the 
contractor  should  utilize  this  guidance  material  as  he  sees  fit,  as  long  as  diagnostic 
requirements  are  met  and  Interfaces  are  controlled.  In  addition,  examples  which  depict 
the  Integration  of  the  various  diagnostic  elements  will  be  of  value  to  both  the  manager  and 
the  designer. 

Guidance  to  the  designer  consists  of  material  contained  In  this  section  and 
Identification  of  additional  guidance  where  published  material  Is  not  readily  available. 
Tools  to  assist  In  the  design  process  are  described  In  Appendix  C,  3.0. 
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GUIDANCE 


The  following  are  references  to  existing  design  criteria  and  guidance. 

General  Guidance 

1 .  MIL-STD-454,  Standard  General  Requirements  for  Electronic  Equipment 

This  standard  covers  the  common  requirements  to  be  used  in  military 
specifications  for  electronic  equipment.  Reliability,  maintainability,  and 
human  engineering  requirements  are  Included  In  this  standard.  However, 
for  these  types  of  engineering  disciplines,  the  guidance  stresses  that  this 
standard  does  not  establish  requirements  and  must  not  be  referenced  In 
contractual  documents.  These  three  requirement  examples  offer  direction 
on  what  should  be  considered  In  preparing  contractual  documents. 

2.  MIL<STD-415,  Design  Criteria  for  Test  Provisions  for  Electronic  Systems  and 
Associated  Equipment 

This  standard  establishes  design  criteria  for  test  provisions  that  permit  the 
functional  and  static  parameters  of  electronic  systems  and  associated 
equipment  to  be  monitored,  evaluated,  or  Isolated.  The  standard.  In  its 
present  form,  (Revision  0)  addresses  older  technologies  and  thus.  If 
referenced  In  contractual  documents,  must  be  tailored  to  address  only 
certain  provislone  In  this  standard. 

3.  The  RADC  Reliability  Engineers  Tool  Kit 

The  Tool  Kit  is  Intended  for  use  by  a  practicing  reliability  and  maintainability 
(R&M)  engineer.  Emphasis  Is  placed  on  his  role  In  the  various  R&M 
activities  of  an  electronic  systems  development  program.  The  Tool  Kit  Is  a 
compendium  of  useful  R&M  reference  Information  to  be  used  In  everyday 
practice. 

4.  Study  of  the  Causes  of  Unnecessary  Removals  of  Avionics  Equipment 
(RADC-TR-83-2) 

This  study  cites  and  verifies  the  causes  of  unnecessary  removals  of  suspect 
items  from  avionics  equipment  and  contains  information  on  minimizing  this 
problem. 
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System  Architecture 

Appendix  E  contains  a  compendium  of  testability  and  diagnostic  design 
techniques,  which  provides  designers  various  approaches  and  techniques  for  achieving 
Improved  testing  of  weapon  systems.  There  are  a  number  of  other  guides,  which  address 
the  architecture  of  the  system  design,  that  promote  improvements  In  the  system's 
diagnostic  capability.  Included  are: 

1.  Architecture  Specification  for  PAVE  PILLAR  Avionics,  January  1987, 
SPA90099001A 

This  specification  addresses  the  advanced  avionics  architecture  which  Is 
specifically  targeted  for  advanced  tactical  fighters  and,  In  general,  for  all 
military  aircraft  applications.  This  architecture  promotes  a  much-improved 
approach,  which  will  foster  an  Improved  diagnostic  capability.  An  example 
of  this  approach  la  contained  later  In  this  section. 

2.  Reliability,  Testability  Design  Considerations  for  Fault  Tolerant  Systems 
(RADO-TR-84-57) 

Furnished  reliability  and  testability  evaluation  and  application  guidance  for 
fault-tolerant  deeigns. 

For  fault  tolerant  systems.  It  is  Important  that  the  design's  Inherent  testability 
provisions  Include  the  ability  to  detect,  Identify,  recover,  and  If  necessary,  reconfigure  and 
report  equipment  malfunctlone  to  operational  personnel.  In  addition,  because  fault 
tolerant  systems  often  aro  characterized  by  complex  non-serial  reliability  blocK  diagrams, 
a  multitude  of  back-ups  with  non-zero  switch  over  times,  and  imperfect  fault  detection, 
isolation,  and  recovery.  It  Is  imperative  that  the  technical  manager  assure  that  effective 
testability  provisions  are  incorporated  In  the  system  design  concept,  If  not,  the  design 
when  fielded  will  exhibit  long  troubleshooting  times,  high  false  alarm  rates,  and  low  levels 
of  system  readiness. 

Fault  tolerance  and  recovery  strategies  will  have  a  significant  impact  on  the 
degree  to  which  testability  Is  designed  into  the  system.  For  example,  when  Incorporating 
testability/diagnostic  capability  Into  the  design,  the  penalties  Imposed  by  a  fault  tolerant 
system  design  which  employs  active  redundancy  and  voting  logic  may  be  less  than  those 
Imposed  by  a  design  employing  standby  redundancy.  With  active  redundancy,  the  prime 
system  hardware  and  software  are  more  readily  adaptable  to  perform  multiple  functions 
(including  those  required  for  testability).  In  active  redundancy  systems  with  voting  logic, 
the  performance/statuo  monitoring  function  assures  the  operator  that  the  equipment  Is 
working  property.  This  approach  also  simplifies  the  Isolation  of  faults  since  the  failure  Is 
easily  Isolated  to  the  locked  out  branch,  by  the  voting  logic.  In  systems  employing 
standby  redundancy,  test  capability  and  diagnostic  functions  must  often  be  designed  Into 
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each  redundant  or  substitute  functional  path  (both  on<llne  and  off-line)  in  order  to 
determine  their  status. 

Although  the  addition  of  redundancy  Is  usually  effective  In  improving  system 
reliability,  the  technical  manager  is  cautioned  that  the  reliability  Improvement  may  be 
highly  dependent  on  achievable  FD/FI  levels.  In  some  oases,  It  is  possible  for  imperfect 
FD/FI  to  actually  cause  system  reliability  to  degrade  as  more  redundant  equipment  Is 
added.  In  general,  the  effect  that  varying  levels  of  FD/FI  have  on  system  reliability  can 
be  evaluated  by  parametric  analyses.  The  range  of  FD/FI  values  used  In  the  analyses 
should  be  based  on  past  experience  with  similar  hardware/software  systems  and  adjusted 
by  evolutionary  trends  and  expectations  for  state-of-the-art  devices  and  designs. 

Teat  Methodology  for  Fault  Tolerant  Systems  -  The  following  discusses  a 
number  of  desirable  design  considerations  for  fault  tolerant  system  testability. 

0  Comparison  Method  -  An  effective  method  for  testing  similar  systems  with 
similar  inputs  and  outputs  is  to  compare  outputs  and  flag  any  gross 
disagreements.  A  means  to  determine  which  branch  is  faulted  and  an  error 
log  entry  should  be  mandatory. 

o  Redundancy  Verification  •  Each  redundant  path  should  be  tested  Individually 
to  prevent  the  mashing  of  faults  in  redundant  Hems. 

o  Flexing  of  Spares  -  Periodically  activate  the  built-in-test  of  the  hot  spares, 
log  any  errors  found,  and  report  status  before  these  Items  are  needed  for 
system  operation.  This  will  prevent  a  fauHy  unK  from  being  switched  in  when 
the  system  reconfigures. 

o  Voting  Scheme  Technique  -  A  typical  example  of  a  voting  scheme  technique 
is  to  compare  output  values  from  three  different  sources.  Confidence  Is 
placed  in  that  value  where  at  least  two  of  the  three  sources  agree.  Errors 
found  should  be  logged,  and  the  source  of  the  erroneous  value  should  be 
recorded  and  corrected  at  an  appropriate  maintenance  Interval.  Since 
diagnostic  procedures  are  generally  designed  to  locate  a  single  fault, 
potential  exists  for  the  occurrence  of  multiple  faults  (e.g.,  a  stucK-at-1  in 
multiple  locations)  than  can  go  undetected.  It  may  be  necessary  to  add 
logic  or  test  circuitry  to  ensure  that  each  state,  and  each  state  transition, 
occurs  correctly. 

o  Error  Correction  -  Detection  of  degraded  performance  In  states  preceding  an 
error  correcting  function  Is  difficult  since  the  error  correcting  function  makes 
Its  preceding  degraded  state  appear  healthy.  The  error  correcting  functions 
should  keep  count  of  the  number  of  times  a  correcting  function  had  to  be 
made  and  a  record  made  in  an  error  log.  When  a  predetermined  threshold 
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count  is  exceeded,  a  test  signal  may  be  injected  to  determine  if  the  Input 
stage  Is  unacceptably  degraded. 

0  Multiple  Redundancy  •  In  redundant  systems,  which  are  allowed  to  degrade 
gracefully  through  failures  of  redundant  elements,  a  test  should  be 
established  to  verify  that  minimum  acceptable  system  performance  and 
redundancy  levels  are  available  at  the  start  of  a  mission. 

o  Caution  Indications  ■  Fault  tolerance  can  be  applied  to  a  variety  of  system 
types  (i.e.,  electrical,  mechanical,  hydraulic,  environmental,  etc.). 
Regardless  of  the  system  type,  It  Is  customary  to  Include  a  cautionary 
Indication  whenever  a  back-up  system  is  called  Into  service,  especially  for 
safety  critical  functions. 

Fault  Detection  Latency  Times  •  One  of  the  most  rigid  demands  Imposed  upon  the 
testability  design  of  fault  tolerant  systems  is  the  quick  response  time  necessary  to 
reconfigure.  Hence,  the  testability  design  process  must  take  Into  account  both  spatial  and 
temporal  considerations  for  fault  detection.  The  failure  detection  approach  selection  must 
be  based  upon  the  requirement  for  maximum  acceptable  failure  latency.  Continuous 
failure  detection  techniques  should  be  used  to  monitor  those  functions  that  are  mission 
critical  and/or  affect  safety  and  where  protection  must  be  provided  against  the 
propagation  of  errors  through  the  system.  Periodic  testing  may  be  used  for  monitoring 
those  functions  which  provide  backup/standby  capabilities  or  are  not  mission  critical. 
Operator  Initiated  testing  is  typically  used  for  monitoring  those  functions  which  require 
operator  Interaction,  sensor  simulation,  etc.,  or  which  are  not  easy,  safe,  or  cost-effective 
to  Initiate  automatically.  The  maximum  permitted  latency  for  failure  detection  determines 
the  frequency  at  which  diagnostic  procedures  should  be  run  and  must  take  Into  account 
function  criticality,  failure  rate,  possible  wear  out  factors,  and  the  overall  maintenance 
concept. 

Teetablllty 

There  are  a  number  of  guidance  documents  which  address  testability  Issues. 
Some  of  these  are  listed  below.  These  deal  with  the  design  techniques  of  controllability, 
observability,  and  partitioning.  Controllability  Is  a  design  attribute  which  describes  the 
extent  to  which  signals  of  Interest  may  be  controlled  by  the  test  process.  It  relates  to 
difficulty  of  test  generation,  length  of  test  sequence,  and  diagnostic  resolution. 
Observability  Is  another  design  attribute  which  describes  the  extent  to  which  signals  of 
Interest  may  bo  observed  by  the  test  process.  The  emphasis  Is  upon  selection  of  the 
most  appropriate  test  points.  Partitioning  oeals  with  both  the  physical  hardv/are  and  the 
functional  partitioning  of  the  circuitry.  Test  times  and  test  generation  costs  escalate 
rapidly  as  partitioning  size  Increases. 

1 .  RADC  Testability  Notebook,  Final  Technical  Report,  June  1982 
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This  notebook  prassnts  a  consolidation  of  Information  relating  to  testability 
design  techniques,  procedures,  cost  trade-off  tools,  and  the  relationship  of 
testability  to  other  design  disciplines  and  requirements.  Specific  examples 
of  good  testability  design  are  contained  In  this  document. 

2.  MIL*STD>2165,  Testability  Program  tor  Electronic  Systems  and  Equipments 

Appendix  B  of  MIL-STD*2165  cites  a  series  of  factors  which  affect  the 
Inherent  testability  of  a  weapon  system.  This  Information  can  be  used  either 
as  design  guidance  or,  If  weighted  and  scored,  can  actually  provide  a  Figure 
of  Merit  for  a  specific  system/unit. 

3.  Testability  Analysis  Handbook  (Draft) 

At  the  time  of  printing  the  Contractor  Program  Managers  Guide,  the 
Testability  Analysis  Handbook  was  in  draft  form.  Publishing  Is  scheduled 
during  FY8Q,  The  Preparing  Activity  Is  the  Naval  Sea  Systems  Command, 
CEL-DST.  This  handbook  provides  a  systematic  methodology  for 
Implementing  testability  analysis  and  design  requirements,  which  are 
prescribed  In  MIL-STD-2165,  Tasks  201 , 202,  and  203. 

4.  Predictions  of  Organizational  Level  Testability  Attributes  (RADC>TR*87*55) 

This  report  documents  a  methodology  for  predicting  fraction  of  faults 
detected,  fraction  of  faults  Isolated,  and  fraction  of  false  alarms  utilizing  field 
measured  data. 

BulH-ln  Teat 


1.  Built-In  Test  Design  Quide-Joint  AMC/CNO/AFLC/APSC  Commanders, 
April  1987 

This  Joint  Service  BIT  Design  Guide  provides  detailed  guidelines  on  the 
Implementation  of  BIT,  including  BIT  design  techniques  at  all  levels  within 
the  weapon  system. 

2.  Smart  BIT  (RADC-TR-85-1 48) 

Application  of  Artificial  Intelligence  techniques  In  the  design  of  BIT,  to 
minimize  false  alarms,  retest  OKs  and  non-requlred  maintenance. 

3.  Sensor  Handbook  for  Test,  Monitoring,  Diagnostic,  and  Control  System 
Applications  to  Military  Vehicles  and  Machinery,  National  Bureau  of 
Standards 
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. .  . . .  II.  ■  I  . . . — 

This  handbook  is  Intendsd  as  a  guide  for  those  who  design,  specify,  use, 
and  test  weapon  systems  containing  monitoring  sensors.  The  handbook 
addresses  measures  and  principles  of  measurement,  data  acquisition, 
sensor  calibration  and  testing,  environmental  considerations,  stability, 
durability,  reliability,  and  error  assessment  for  various  types  of  sensors. 

4.  Analysis  of  BulIMn  Teat  (BIT)  False  Alarm  Conditions  (RAOC*TR-81-220) 

This  study  analyzes  the  root  causes  of  the  false  alarm  problem  and  provides 
design  guidelines  for  avoiding  BIT  false  alarms. 

5.  Design  Quideliras  and  Optimization  Procedures  for  Test  Subsystem  Design 
(RADC-TR-80.111) 

This  study  provides  guidelines  and  procedures  to  optimize  the  design  of 
built-in  teat. 

6.  BIT  Verification  Techniques  {RADC‘TR-88-241) 

This  report  covers  practical  verlfloatlon  techniques  for  formal  and  field 
demonstration  of  BIT  effectiveness. 

The  problem  of  Bullt-ln-Test  False  Alarms  and  Cannot  Duplicates  have  plagued 
design  for  many  years.  These  problems  must  receive  the  full  attention  of  system 
designers.  Future  generations  of  BIT  must  Include  more  emphasis  on  Interpretation  of 
detected  system  anomalies  and  better  accounting  for  real  world  system  operating 
conditions  such  as  fielded  system  performance,  environmental  and  operational  factors. 

In  order  for  the  BIT  to  reach,  and  remain  at,  Its  full  potential  In  the  field.  It  must 
be  designed  with  sufficient  flexibility.  Including  the  ability  to  easily  adjust  test  limits  and  to 
change  BIT  software  without  affecting  tactical  software. 

According  to  the  above  referenced  document  "Analysis  of  Bullt-ln-Test  (BIT) 
False  Alarm  Conditions",  a  common  cause  of  false  alarms  are  sudden  environmental 
stresses  such  as  momentsry  high  temperatures,  or  a  high  "Q"  turn.  The  Rome  Air 
Development  Center,  at  the  time  of  this  printing.  Is  developing  a  Time  Stress 
Measurement  Device  (TSMD)  chip  which  will  monitor  and  categorize  (In  compacted  form) 
data  relative  to  the  temperature,  axial  vibration  and  shock,  and  power  quality  that  the 
equipment  sees  over  time.  A  larger  module  has  already  been  developed  and  flight  tested 
which  can  monitor  such  characteristics.  In  the  future,  BIT  Indications  can  be  correlated 
with  TSMD  data  to  help  eliminate  the  occurrence  of  false  alarms  and  CNDs.  The 
Integration  of  BIT  Indications,  TSMD  data,  and  smart  (artificial  Intelligence)  processing 
may  also  potentially  yield  even  greater  accuracy  for  onboard  diagnostics. 
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AutomaUe  Tot  Equipment  (ATE) 

1 .  Modular  Automatic  Tast  Equipment  (MATE)  Handbook 

Although  Air  Forca<orlented,  this  handbook  describe  procedures  and 
techniques  for  acquiring  automatic  test  equipment. 

2.  MIL-STD-2077,  General  Requirements,  Test  Program  Seta 

This  standard  covers  the  acquisition  of  test  program  sets  for  use  with  ATE. 
Design  criteria  Is  included,  which  addresses  many  detail  requirements  for 
TPSs. 

Human  Engineering 

1.  MIL-STD-1472,  Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment,  and  Facilities 

This  standard  covers  general  human  engineering  design  criteria  which  can 
be  applied  to  any  weapon  system. 

Technical  Information 

There  are  a  variety  of  standards  which  address  the  preparation  of  technical 
publications.  Most  of  these  documents  are  directed  at  a  specific  military  service.  All 
address  the  delivery  of  paper<type  documentation.  There  Is  no  firm  guidance  relating  to 
other,  perhaps  more.  Innovative  means  for  generating  and  delivering  technical 
Information.  In  the  past,  many  technical  publications  have  been  cited  to  have 
deficiencies.  These  deficiencies  can  best  be  described  In  the  DoD  Audit  Report  No.  87- 
1 15,  April  3,  1987,  "Summary  Report  on  the  Defense-Wide  Audit  on  Acquisition  of 
Technical  Manuals  and  Related  Data  From  Contractors." 

Means  should  be  sought  for  generating  and  delivering  this  technical  Information 
In  a  less  costly  manner,  without  compromising  its  quality.  There  are  a  number  of  tools 
available,  or  under  development,  which  can  assist  the  designer  of  this  technical 
Information  In  authoring  the  text,  when  electronic  delivery  of  technical  information  Is 
contemplated.  Some  guidelines  and  standards  for  automatic  generation  of  technical 
Information  and  Its  delivery  electronically  can  be  obtained  from  the  Human  Resources 
Laboratory  at  Wright-Patterson  Air  Force  Base.  This  guidance  Information  has  been 
developed  under  the  Integrated  Maintenance  Information  System  (IMIS)  Program. 

Innovative  Ideas  for  displaying  this  technical  Information  are  encouraged,  as 
stipulated  In  Task  303,  MIL-STD-1 386-1.  Care  should  be  taken  to  provide  for  quick 
access  to  the  required  data.  For  electronic  delivery  of  this  data,  formats  may  vary 
substantially  from  paper-based  technical  manuals.  Previously  specified  access  times  and 
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Information  modification  timas  should  Influence  the  type  of  generation  and  delivery 
methods.  DoD'Instructlon  4151.9  requires  the  services  to  plan  and  schedule  the 
acquisition  of  technical  manuala  (technical  Information)  to  ensure  their  availability  In  final 
form  before,  or  concurrently  with,  delivery  of  the  system  to  the  field.  During  design,  final 
plana  should  be  developed,  along  with  the  support  equipment  which  Is  furnished. 

Maintenance  Aide 

There  Is  a  need  to  present  technical  Information  and  troubleshooting  advice  to 
the  technician  on  location  and  readily  available  for  his  use.  The  maintenance  aid, 
sometimes  called  a  Job  performance  aid,  presents  Information  generated  by  experts  to 
assist  the  less*expericnced  technician. 

The  maintenance  aid  Is  a  device,  publication,  or  guide  used  on  the  job  to 
facilitate  performance  of  maintenance.  It  delivers; 

0  Historical  Information  on  what  fault  was  found  when  similar  symptoms  were 
experienced 

o  Troubleshooting  logic  to  assist  in  finding  the  fault 

0  Procedural  Information  which  assists  the  technician  In  finding  and  correcting 
a  failure. 

Normally,  a  maintenance  aid  Is  used  In  conjunction  with  a  testing  capability. 
Maintenance  aide  could  be  paper-based  or  employ  eleotronio  delivery  systems. 

Electronic  delivery  of  this  type  of  Information  opens  the  door  to  solving  some  of 
the  problems  associated  with  paper  maintenance  aids.  Two  attributes  of  eleotronio 
delivery  syatema  are: 

o  Information  can  be  available  to  the  technician  In  a  matter  of  seconds  by 
carefully  oonatruoted  menus.  In  lieu  of  the  technician  having  to  page 
through  a  paper  document. 

o  The  collection  of  historical  data  and  the  subsequent  modification  to  the 
software  programs  which  deliver  this  technical  Information  can  be  updated 
In  a  matter  of  seconds.  Instead  of  a  matter  of  months. 

This  latter  attribute  lends  Itself  to  the  introduction  of  expert  systems,  which  often 
employ  artificial  Intelligence  technology.  The  expert  system  has  the  capability  of 
combining  various  pieces  of  Information  to  lead  the  technician  to  a  logical  decision  on 
what  Is  faulty  and  how  It  can  be  repaired. 
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Anothtr  important  aspact  of  tha  maintananca  aid  Is  its  ability  to  train  tachnicians 
on  tha  |ob.  Training  programs  must  ba  closely  associated  with  tha  design  and 
davalopmant  of  a  maintananca  aid. 

Over  tha  past  20  yaara,  many  maintananca  aids  have  bean  designed, 
davalopad,  and  tasted.  These  tests,  for  tha  moat  part,  have  proven  successful.  However, 
tha  transition  of  these  maintananca  aids  Into  tha  field  has  not  bean  accomplished  to  any 
great  extant.  One  of  tha  reasons  la  that  spaclfloatlons,  standards,  and  guidance 
Information  on  how  to  Invoke  this  requirement  are  lacking. 

A  few  Important  facts  should  be  remembered  when  applying  maintenance  aids 
and  expert  systems. 

0  The  design  of  the  maintenance  aids  must  be  done  with  the  user  In  mind. 
Once  a  working  model  of  the  equipment  Is  available,  there  should  be  a 
dynamic  Interchange  of  Information  between  the  maintenance  technician 
and  the  design  engineer  to  ensure  an  effective  and  efficient  man«machlne 
Interface  la  attained. 

0  User  acceptance  and  adoption  of  maintananca  aids  will  be  facilitated  In 
cases  where  potential  users  are  given  a  trial  period  In  which  to  become 
familiar  with  thase  devioas  prior  to  their  formal  Implementation. 

0  A  system  must  be  devised  to  assure  timely  updating  of  Information  to 
correct  errors  and  to  add  newly  acquired  Information.  Without  such  a 
systam,  the  maintenance  aid  will  quite  rapidly  become  obsolete. 


Manpower  and  Training 

After  personnel  and  training  requirements/allooatlons  have  been  made,  the 
training  curriculum  needs  to  be  established  concurrently  with  the  system  detail  design. 
This  Includes  the  formal  schooling  curriculum,  as  well  as  on-the-job  training.  One  of  the 
alternatives  available.  If  electronic  delivery  of  technical  Information  Is  employed.  Is 
combining  training  aids  with  the  delivered  technical  Information.  These  two  types  of 
Information  (aiding  and  training)  are  somewhat  similar  In  nature  and,  at  times, 
Indistinguishable.  The  training  curriculum  should  be  aimed  at  the  U8er($)  and  accessed  In 
a  mannar  which  can  be  utilized  by  a  variety  of  users. 

These  training  devices  can  be  freestanding  or  embedded  in  the  prime  system. 
They  can  serve  as  just  mairitenance  training  devices  or  they  can  be  Incorporated  with 
operational  training.  Separate  and  distinct  training  devices  (maintenance  trainers)  may  be 
required  to  be  developed  for  the  formal  schooling. 
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PROGNOSTICS 

Although  raroly  eonaidorad  In  alactronlo  ayatam  daaign,  prognostics  (Inolplant 
fallura  dataotlon)  taohniquas  may  have  a  significant  Impact  In  Improving  tha  oparatlonal 
raadinass  and  mission  suocass  rata  of  future  systams.  Having  tha  ability  to  tast  an 
equipment  to  sea  If  any  of  Its'  critical  components  are  soon  to  fall  could  radically  change 
tha  repair  philosophy  for  a  system.  An  RADC  study  entitled  "Marginal  ChaoKIng" 
Indicated  that  often  prognostics  techniques  must  be  developed  on  an  Item  by  Item  basla. 
This  being  the  case,  It  makes  sense  to  concentrate  first  on  developing  techniques  for 
detecting  Incipient  failure  of  high  failure  rate  critical  components.  The  "Marginal 
Checking"  study  has  Identified  potential  prognostics  techniques  which  are  appropriate  to 
cables,  power  supply  bridge  reotiflera  and  CMOS  circuitry. 

Integration  of  Dlagnostlo  Elements 


There  are  a  variety  of  ways  In  which  dlagnostlo  elements  can  be  Integrated  to 
produce  a  more  effective  and  efficient  diagnostic  capability.  Expert  system  technology 
can  be  Incorporated  In  either  ATE  or  BIT  to  supplement  the  basic  testing  capability.  Fault- 
tolerant  design  and  testability  design  can  be  Introduced  Into  prime  system  architecture  to 
promote  ease  of  testing,  along  with  graceful  degradation.  Maintenance  aiding  and 
maintenance  training  can  be  oomblned  to  provide  on-the-job  maintenanoe  and  training 
Information,  utillaing  a  single  portable  device  or  embedded  Into  the  prime  system.  Two 
examples  of  this  type  of  Integration  follow. 

ADVANCBD  AVIONICS  ARCHITBCTURB  ■XAMPLM  AS  BMBODUD  IN  THE  FAYl 
Fli-LAR 

Advanced  Modular  Avionloa  DIagneatIo  Requirements 

Mission  availability  and  probability  of  mission  success  expectations  for 
advanced  modular  avionic  architectures  such  as  PAVE  PILLAR  are  totally  dependent 
upon  the  embedded  diagnostic  capability  that  Is  Implemented  as  an  Integral  part  of  the 
design.  The  Implication  of  this  statement  represents  a  significant  departure  from  the 
traditional  relationship  that  has  existed  between  the  circuit  design  and  BIT/teatablllty 
disciplines.  An  overview  of  the  PAVE  PILLAR  modular  avionloa  architecture  with  Its 
Integral  diagnostic  features  Is  provided  In  the  paragraphs  that  follow  to  facilitate  an 
understanding  of  the  new  relationship  that  must  be  developed. 


3-25 


CRITERIA  FOR  DESIGNING  DIAGNOSTIC  CAPABILITY _ REQUIREMENT  #3.2 

PAVE  PILLAR  Ov«rvl«w: 

PAVE  PILLAR  Is  a  highly  modular  fisxibla  avionic  systam  arohitactura  which 
amployo  a  common  modula  sat  to  axplolt  the  commonality  In  alr-to*alr  and  alr*tO'ground 
missions.  Tha  major  functional  partitions  of  tha  avionics  suits  are;  Digital  Signal 
Procassing,  Mission  Procasaing.  Vahicia  Management  Processing,  and  Avionics  Systam 
Control.  Figure  7  depicts  tha  enclosing  boundaries  (l.a.,  Digital  Signal  Procassing, 
Mission  Processing,  and  Vehicle  Management  Processing)  tor  resource  sharing,  sparing, 
and  substitutions.  Tha  unique  oharactaristlcs  of  tha  functions  within  each  of  these 
boundaries  praeluHa  tha  utilization  of  resources  across  boundaries  for  tha  purpose  of 
recovery  or  rscon(i{)ur  ’  tion.  As  a  consequence  of  this  partitioning,  the  diagnostic  process 
takes  place  within  a  boundaries  and  the  associated  results  are  communicated  across 
the  boundaries  to  provide  the  pilot  with  the  required  system  status.  The  system 
srchlteoture  which  supports  the  diagnostic  process  Is  described  In  the  paragraphs  below. 

Diagnostic  Strategy: 

The  PAVE  PILLAR  advanced  system  architecture  employs  a  hierarchical 
approach  that  spans  system  elements  from  the  Individual  chips  to  the  entire  system. 
Essential  features  of  this  hierarchical  diagnostic  architecture  are  shown  In  Figure  6.  The 
Incorporation  of  a  test  control  function  at  each  level  of  fault  detection  (l,e,,  chip,  LRM, 
subsystem,  and  system)  can  facilitate  both  fault  screening  and  test  augmentation 
functions.  The  Inherent  flexibility  provided  by  this  architecture  provides  ths  system 
designer  the  ability  to  meet  weapon  system  specific  diagnostic  requirements  with  s  suits 
of  standsrd  modules. 

It  Is  essential  that  both  the  system  end  detail  designer  recognize  the  Importance 
of  Implementing  such  a  hierarchical  diagnostic  structure.  A  suite  of  standard  line 
replaceable  module  (LRMs)  will  have  Individual  fault  detection,  fault  Isolation  and  false 
alarm  rate  specifications  that  are  not  necessarily  adequate  to  meet  the  system-level 
requirements  imposed  without  fault  screening  and  test  augmentation.  Advanced  BIT 
concepts,  which  have  been  Introduced  through  the  "Smart  BIT"  project,  are  both 
compatible  and  dependent  upon  the  availability  of  a  hierarchical  diagnostic  architecture. 
A  representative  diagnostic  Implementation  Is  provided  In  Figure  9. 

LRM  Bus  Struoture: 

The  bus  structure  associated  with  the  diagnostic  system  Implementation,  shown 
In  Figure  9,  Is  dependent  upon  local  maintenance  and  data  buses,  as  well  as  system  level 
multiplex  data  communications.  At  the  chip  and  module  level,  the  primary  diagnostic 
control  Is  provided  over  the  VHSIC  Phase  2  defined  TM  •  Bus. 
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FIGURE  7.  -  COMMON  ARCHITECTURE 


nCURE  8.  CHAGNOSnC  STRATEGY 
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FIGURE  9.  DIAGNOSTIC  SYSTEM  IMPLEMENTATION 


CRITERIA  FOR  DESIGNING  DIAGNOSTIC  CAPABILITY  REQUIREMENT  |3.2 

Communication  of  diagnostic  Information  between  subsystems  within  the  major 
PAVE  PILLAR  partitions  (I.e.,  Signal  Processing,  Mission  Processing,  and  Vehicle 
Management  Processing)  takes  place  over  the  respective  partition  Multiplex  Bus.  This 
configuration  permits  the  use  of  a  separate  diagnostic/maintenance  processor,  or  the 
Incorporation  of  these  functions  within  the  mission  processing  function.  This  diagnostic 
system  Implementation  la  also  compatible  with  the  requirements  for  the  System  Status 
function,  as  currently  defined  under  the  Pilots  Associate  Program.  (The  Pilots  Associate 
Program  Is  sponsored  by  the  Defense  Advanced  Research  Projects  Agency  under 
Program  Element  Number  62301 E.  The  performing  activity  Is  the  Wright  R&D  Center 
(WRDC). 

Diagnostic  Applications,  Summary  and  Concluaiona: 

The  diagnostic  architecture  described  above  Incorporates  all  the  necessary 
functions  to  support  the  following  operational  and  diagnostic/testablilty  objectives: 

Fault  Detection 
Fault  Screening 

Fault  Isolation  (Controllablitty,  Observability) 

Fault  Recovery  (Redundancy,  Reconfiguration,  or 
Graceful  Degradation) 

System  Status  Indication 
Maintenance  Data  Recording 
Repair  Vertfloatlon 

Off-Board  Maintenance  Interface  (IMIS) 


In  additional  to  the  complete  range  of  functions  Identified,  the  hierarchical 
diagnostic  architecture  offers  sufficient  flexibility  for  the  system  designer  to  achieve  the 
weapon  system  supportablllty  required.  The  layered  access  to  the  diagnostic  capability 
within  the  system  Is  essential  for  the  application  of  artificial  Intelligence  based  BIT 
techniques  being  developed  under  programs  such  as:  Smart  BIT,  Flight  Control 
Maintenance  Diagnostic  System,  Pilots  Associate,  etc.  (These  latter  two  programs  are 
being  performed  by  the  Wright  R&D  Center  (WRDC),  WPAFB,  Ohio.) 

B-1B  EXAMPLE  OF  DIAGNOSTIC  IKTE0RAT10N 

The  B-1B  Bomber  provides  an  example  of  many  different  facets  of 
diagnostics  deliberately  combined  to  provide  a  total  Integrated  diagnostics 
capability.  The  diagnostic  elements  Include  conventional  and  artificial  intelligence 
diagnostic  techniques,  real-time  in-flight  performance  monitoring  and  ground 
readiness  testing,  system  performance  monitoring  for  aircrew  Information  and  LRU 
fault  Isolation  for  maintenance  personnel,  detailed  embedded  data  acquisition 
equipment  and  ground  processing,  standard  Inspection  and  other  scheduled 
maintenance  tasks  (primarily  In  mechanical  areas),  and  status  Information 
developed  by  the  defensive  and  offensive  avionics. 
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As  shown  In  Figure  10,  the  core  of  the  diagnostics  is  an  on>board 
Central  Integrated  Test  System  (CITS).  The  general  philosophy  of  CITS  is  to 
monitor  and  record  activity  on  the  aircraft  equipment  buses  as  well  as  performance 
status  Information  generated  by  the  defensive  and  offensive  avionics  system. 
Signal  levels  are  compared  to  standards  by  the  CITS  computer.  In  the  event  of  a 
failure,  a  CITS  Maintenance  Code  (CMC)  Is  generated  Identifying  the  faulty  LRU. 
Both  the  CMC  and  measured  signal  levels  are  recorded  for  later  analysis  by  a 
ground  processor  located  in  the  Intermediate  shop. 

Embedded  equipment  which  makes  up  CITS  Include  four  data  acquisition 
units,  a  CITS  computer,  an  airborne  printer,  a  CITS  control  and  display  panel,  and 
the  CITS  maintenance  recorder. 

Associated  ground  equipment  Is  the  CITS  Ground  Processor.  It  Is  used 
for  retrieving  and  Interpreting  the  data  recorded  during  each  flight.  The  artificial 
intelligence  portion  of  the  diagnostics  (CITS  Expert  Parameter  System  or  CEPS)  Is 
also  resident  In  a  separate  ground  computer.  The  CITS  Ground  Processor  Is  used 
to  evaluate  the  maintenance  codes  recorded  in  flight  and  Issue  work  orders  directing 
the  removal  of  the  faulty  LRU.  CEPS  Is  used  when  the  CMC  does  not  Isolate  the 
fault  to  single  LRU.  CEPS  utilizes  past  history,  expert  diagnostic  approaches,  and 
monitored  environmental  data  at  the  time  of  the  failure  to  further  break  the  CITS 
ambiguity  groups  for  Isolation  to  the  single  failed  LRU. 

Technical  Orders  (TOs)  and  crew  training  still  play  an  Important  part  in  the 
overall  diagnostics.  Ground  readiness  tests  are  manually  Initiated  following  an  LRU 
replacement.  These  tests  are  to  assure  proper  system  operation.  They  are 
performed  per  Instructions  In  the  TOs  using  the  applicable  tests  of  CITS.  In  addition 
there  are  limited  physical  Inspections  directed  by  the  TOs  covering  the  traditional  but 
still  effective  monitoring  of  wear  and  fluid  contamination. 

The  design  process  of  Integrating  ail  of  the  above  centered  around  three 
established  disciplines.  They  are  1)  a  structured  systems  engineering  approach,  2) 
a  Failure  Mode,  Effects,  and  Criticality  Analysis  (FMECA),  and  3)  Logistic  Support 
Analysis  and  Support  Equipment  Recommendation  Data  development. 

CITS  design  manuals  governed  the  systems  engineering  process.  These 
manuals  were  created  following  MIL-Standard  software  development  specifications 
and  associated  reviews.  A  basic  document  called  CITS  Autoflow  was  created  for 
each  system/subsystem  which  delineated  the  tests  to  be  made  for  fault  detection 
and  isolation.  The  Autoflow  Identifies  which  Inputs  and  outputs  from  each  box  are  to 
be  checked  to  assure  that  the  problem  Is  within  the  box  and  not  caused  externally. 
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FIGURE  10.  B-1B  MAINTENANCE  CONCEPT 


3-32 


CRITERIA  FOR  DESIGNING  DIAGNOSTIC  CAPABILITY 


REQUIREMENT  #3.2 


A  detailed  Failure  Modes,  Effects  and  Criticality  Analysis  (FMECA) 
provided  the  initial  basis  for  selecting  CITS  tests.  This  was  augmented  by  a 
structured  LSA  which  identified  all  diagnostic  tasks  required  to  be  accomplished. 
Part  I  Support  Equipment  Recommendation  Data  (SERD)  was  created  documenting 
the  need  for  all  applicable  support  equipment.  CITS  personnel  then  evaluated  each 
SERD  and  where  possible  made  sure  that  the  requirement  was  met  by  CITS. 
Where  applicable,  other  visual  Inspections,  etc.,  were  also  considered.  All  SERD 
requirements  were  eventually  satisfied  without  the  use  of  a  significant  amount  of 
ground  support  equipment. 
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CHECKLIST 

□f  Are  available  design  criteria,  rules,  and  other  available 
guidance  documentation  being  used? 

Is  the  Integration  of  the  various  diagnostic  elements 
belna  accomplished  to  provide  a  more  effective  and 
efficient  diagnostic  capability? 

□f  Is  design-for-test  on  Integral  part  of  the 
system  design  process? 


of  test? 


of  Have  the  general  design  considerations  and  the  standard 
testability  approaches  been  thoroughly  evaluated  and 
^ade  o^s  performed? 

Move  appropriate  fault  Isolation  techniques  been 
Incorporated  Into  the  overall  approach? 

Ei  Has  the  Impact  of  the  physical  packaging  of  the  system 
been  thoroughly  evaluaiea? 

Ei  Has  a  test  and  maintenance  bus  been  considered  for 
Integration  Into  the  qystem? 


ANALYSIS  AND  ASSESSMENT  OF  THE  PERFORMANCE  OF  THE  DIAGNOSTIC 


CAPABILITY 

OVERVIEW 

Throughout  the  design  of  the  weapon  system's 
diagnostic  capability,  It  Is  essential  to  analyze, 
assess  and  demonstrate  Its  performance.  Such 
assessments  are  an  Integral  part  of  logistics, 
reliability,  maintainability,  testability,  human 
engineering,  software  and  safety  programs.  The 
ability  to  properly  conduct  these  analyses, 
assessments,  and  demonstrations  Is  hampered  by 
the  lack  of  available  techniques  and  tools  to  help, 
and  the  Incompatibility  of  the  available  tools  and 
techniques  to  function  together,  Thus  both  the 
program  manager  and  the  designer  must  have 
sufficient  Knowledge  to  understand  the  processes 
utilized  and  Integrate  these  processes  and  tools  to 
do  the  best  possible  Job. 


IMPORTANT  CONSIDERATIONS  TO  BE  ADDRESSED 

Reamt. 

4.1  Analyele  and  aeaeasment  of  the  diagnostic  capability  should  be 
performed  for  the  entire  diagnoetic  capability,  as  well  as  for  each 
diagnoatio  element 

4.2  Maintainability  demonstrations  should  be  designed  to  verify  that 
olagnostio  requirements  have  been  meL 
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WEAPON 
SYSTEM 
ACQ.  PHASE 


OPER.  CONCEPT  DEM/ 

REQMTS.  EXPLOR.  VAL 


PROD/ 

DEPL 


WEAPON 

SYSTEM 

ACTIVITIES 

SYSTEM  PREL  DETAIL 

SPEC.  DESIGN  DESIGN 

DIAGNOSTIC 

ACTIVITIES 

A  A  A 

IN-PROCESS  ASSESSMENTS 

PIAQNOSTICACnVfTY 

During  Dtm/Val  and  PSD,  It  it  Important  to  ataais  whathar  tha 
tastablllty/dlagnoatio  raquiramanta  ara  baing  achlavad.  Thia  activity  aneompaaaaa  all 
prallmlnary  and  (ulLacala  anginaaring  activltlaa  partalning  to  both  tha  ambaddad  and 
axtamal  diagrwatio  capability. 

pRQggpvne 

In^procasa  taatablllty/dlagnostic  analyaaa  can  ba  conductad  at  moat  any  tima 
within  Dam/Val  and  PSD,  Thaaa  ln*prooaaa  analyaaa  ara  typically  ravlawad  by  tha 
govammant  at  Prallmlnary  Daaign  Ravlawa  and  Critical  Daalgn  Ravlawa.  Thaaa  analyaaa 
ara,  for  tha  moat  part,  Implamantad  par  MIL-STO-2165  (Taak  202,  Prallmlnary  Daalgn, 
and  Taak  203,  Datall  Daalgn).  Normally,  thaaa  analyaaa  will  ba  the  raaponalbillty  of  tha 
daalgn  or  teat  anginaar. 
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ftyiBANQt 

Baalcally,  th«r«  ar«  two  typos  of  in*procosi  snalyses.  Tho  first  deals  with  the 
inherent  testability  of  the  hardware  design  and  is  Independent  of  test  stimuli  and  response 
data.  The  second  type  deals  with  tho  effeotivenesa  of  the  diagnostic  capability  which 
deals  with  measures  that  Include  consideration  of  hardware  design,  embedded 
diagnostics,  and  external  diagnostics.  Diagnostic  effectiveness  measures  Include,  but  are 
not  limited  to,  fault  coverage,  fauH  reaolutlon,  fault  detection  time,  fault  isolation  time,  and 
false  alarm  rate. 

There  are  a  number  of  techniques  and  tools  available,  both  automatic  and 
manual,  which  can  be  used  to  assist  In  these  analyses.  A  thorough  description  of 
available  techniques  Is  contained  In  the  Testability  Analysis  Handbook,  which  la 
referenced  under  Requirement  #3.2.  A  description  of  available  tools  to  assist  In  these 
analyses  Is  oontalned  In  Appendix  C. 

INHERENT  TE8TAEIUTY 

The  first  analysis  deals  with  Inherent  testability.  Inherent  testability  assessment 
Is  an  evaluation  of  how  well  a  design  supports  the  testing  process,  whether  bulK-tn  teat  or 
off'llne  test.  The  evaluation  Is  preformed  on  the  preliminary  design  and  Is  performed 
before  any  test  design  Is  performed.  It  is.  therefore,  based  solely  upon  the  hardware 
design  features,  such  ae  physical  and  eleotrloai  partitioning,  controllability,  observability, 
and  test  point  placement,  etc.  The  Key  to  performing  an  Inherent  testability  aaseasment  is 
the  Identification  of  features  which  support  or  Inhibit  the  diagnostic  process  early,  at  a 
point  In  time  when  the  design  can  be  changed  relatively  easily.  The  concept  and  the 
Implementation  of  an  Inherent  testability  assessment  can  have  great  Impact  on  overall 
system  supportablllty. 

In  general,  three  generic  groups  of  inherent  testability  predictive  techniques  are 
available,  each  with  Its  unique  advantages  and  disadvantages.  Checklists  are  low  cost, 
manual,  and  somewhat  simplistic.  Loolc  models  utilize  the  actual  circuit  topology  but 
often  regard  everything  as  a  block,  with  Inputs  and  outputs.  The  more  detailed 
algorithmic  approaches,  such  as  Sandia  Controllablllty/Observablllty  Analysis  Program 
(SCOAP),  require  libraries  of  the  devices  that  most  nearly  simulate  aotuel  circuit  devices. 

Checklist  approaches  to  Inherent  testability  assessment  have  some  very  good 
characteristics.  Checklists  are  manual  approaches  to  testability  assessment,  yet  are 
easily  automated  Into  an  Interactive  format  for  the  designer  to  Input  design  features  to 
allow  testability  grading.  However,  significant  engineering  analysis  Is  still  required.  Two 
checklists  of  that  type  are  the  RADC  PCB  Testability  Design  Rating  System  and  the  MIL- 
STD-2165  Appendix  B  Checklist.  The  original  RADC  PCB  rating  system  was  limited  to 
lower  density  digital  board  applications,  v.'herea8  MIL-STD-2ie5  Appandix  B  covers 
analog,  digital, a  d  hybrid  applications  from  module  to  system  level.  An  updated  RADC 
PCB  rating  system  now  under  development  will  be  expanded  to  cover  all  modem  digital. 
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analog  and  hybrid  PCBs.  Tha  RADC  rating  ayatam  haa  fixad  Itama  of  waighting,  wharaaa 
MtL>STD*2165  Appandix  B  allowa  aubjacttva  traating  of  Itama  and  Waighting  valuas.  Both 
chackliata  can  ba  utlllzad  aarly  In  daaign. 

Logic  modala  hava  oonaldarabla  auccaaa  and  validity  othar  than  In  aupport  of 
tha  tastablilty  diaolpllna,  Including  Icgiatica,  fault  Isolation,  Intagratad  diagnoatloa,  and 
maintainability.  Tha  logic  modal  algorithma  ara  of  varying  aophlatloatlon  and  validity, 
although  tha  mathodology  for  dafining  dapandanclaa  ara  almilar. 

Logic  modala  ayatama  for  taatabllity  ara  applioabla  to  analog,  digital,  and  hybrid 
appllcationa.  Thay  can  ba  modalad  at  tha  componant,  board,  or  modula  aubayatam  and 
ayatam  laval.  Ona  IlmKatlon  of  thia  broad  approach  la  that  avary  Kam  la  Idantifiad  aa  a  box 
with  Inputa  and  outputa.  Thua,  box  complaxity  might  ranga  from  and  OR  gata  to  a 
oomplata  mlcroprooaaaor.  Tha  aama  variatlona  appllaa  to  tha  llnaa  batwaan  boxaa. 
Critical  aignala,  auoh  aa  a  clock  or  a  ti1>atata  bua  ara  not  mora  Important  than  any  othar 
llna.  Two  of  tha  mora  wall-known  modala  ara  Logic  Modeling  (LOQMOD)  and  Syatam 
Taatabllity  And  Maintananoa  Program  (STAMP).  Both  ara  mature  In  nature,  but  each  la 
tied  to  a  apaclflc  vendor  at  tha  praaant  time. 

Algorithmic  approaohaa  ara  parhapa  tha  moat  lophlatloatad  approach.  SCOAP 
aaama  to  uaually  perform  wall,  but  haa  had  aoma  library  limitatlona  in  tha  important  area 
of  CMOS  primHIvaa.  Soma  CAE  workatatlon  vandora  ara  Including  modified  varaiona  of 
SCOAP  for  up-front  taatabllity  analyaaa.  Daisy  workstations  Include  tha  Daisy  Taxability 
Analyzer  (DTA)  package,  and  QE/CALMA  workstations  Include  tha  Controllability- 
Obaarvablllty-Pradlctablllty-Taatablllty  Report  (COPTR)  package.  Both  hava  Improved  on 
tha  basic  SCOAP,  via  top-down  modeling  and  large  device  modal  libraries  of  the  mora 
common  1C  types.  QanRad  also  haa  a  package  called  HITAP,  which  la  baaed  on  tha 
Computer-Aided  Measure  for  Logistic  Testability  (CAMELOT)  algorithm. 

Another  major  Issue  surrounding  inherent  testability  asaaasment  la  that  many  of 
tha  automated  tools  which  exist  ara  proprietary.  This  proprietary  nature  of  the  tools 
creates  Implementation  problems  from  both  a  coat  and  a  contractual  point  of  view.  Often, 
tha  bast  approach  la  to  utilize  a  nonpropriatary  automated  tool  for  Inherent  testability 

aasassmant. 

Prior  to  tha  PSD  phase,  tha  design  or  test  engineer  should  develop  a  total 
strategy  for  conducting  Inherent  testability  assessment  on  all  systems,  subsystems,  ate. 
Based  upon  tha  availability  and  applicability  of  currant  Inherent  testability  assessment 
approaches.  It  is  anticipated  that  combination  of  tools  and  techniques  will  be  required  to 
form  a  totally  comprahanalva  measurement  capability  In  areas  where  an  automated 
capability  Is  not  available,  use  tha  baseline  of  existing  models  to  make  modifications  to 
provide  tha  total  capability  required. 
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An  •valuation  oritoria  for  Inharant  tastabillty  aaaaaamant  tools  and  taohnlqu«s 
should  b«  dtvolopad  basod  upon  apoolflo  system  and  subsystem  spoolflo  naods.  Tha 
following  list  of  avaluatlon  crttarla  Is  racommandad: 

0  Automation;  dagraa  of  automation 

0  Proprlatery  natura 

0  Usar  friandllnasa 

0  Automated  link  to  daslgn  data  basa 

0  Aooaptablllty  of  output  to  tha  govammant 

0  Coatofuaa 

0  Availability  (ourrantly  availabla  or  undar  davalopmant) 

0  Quality 

0  Sanaltivlty  to  kay  taatablllty  faaturas 
0  Faadbaok  provldad  (doaa  It  raoommand  daslgn  fixaa?) 

0  Comprahansivanaas  (cHgltal,  anatog,  RF,  VHSIC,  maohanloal.  ato.) 

0  Qanaral  teohniquaa;  prlndplaa  uaad 

s 

0  Link  to  teat  affaottvanasa  pradlotion  taohnlqua 
0  Output  raporta 
0  Soaring  mathodology 
0  Applicability  to  chip,  board,  subsystem 

TIST  IPFlCnVINISS 

Tha  saoond  typa  of  analysis  daals  with  test  affsotlvanass.  Traditional 
approachas  to  datorminlng  test  affaotlvanass  call  for  tha  gsnaratlon  of  test  saquancas  at 
tha  complatlon  of  tha  daslgn  phasa  and  a  maasura  or  maasuras  mada  of  thair 
affaotlvanass.  Tha  analysis  naad  not  wait  on  tha  complatlon  of  BIT  and/or  off'llna  TPS 
softwara,  Modaling  Is  anoouragad,  sinoa  this  approach  oan  analyze  tost  affaotlvanass  on 
a  large  number  of  postulated  faults  prior  to  incorporating  tha  test  stimulus  In  either  an 
•mbaddad  or  off-line  program.  Tha  results  of  tha  analysis  can  feed  forward,  so  as  to 
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lnflu«not  BIT  or  TPS  software  design,  and  feed  backward  to  Influence  possible  redesign 
of  the  primary  system  to  Improve  Its  testability.  Test  effsctiveness  measures  have 
traditionally  Included: 

0  Fault  coverage 

0  Fault  resolution 

0  Fault  detection  time 

0  Fault  isolation  time 

Computer  programs  are  used  to  Input  (via  software)  a  large  number  of  faults 
Into  the  software  model  of  the  hardware  item  (UUT).  The  response  of  the  simulated  Item 
to  the  test  sequence  Is  then  evaluated,  given  the  presence  of  the  simulated  faults.  Fault 
detection,  resolution,  etc.,  are  automatically  ascertained.  Most  modern  Automatic  Test 
Program  Qeneration  (ATPQ)  and  simulation  systems  have  very  efficient  fault  simulatiort 
capabilities.  The  HITS  system,  for  example,  runs  a  concurrent  fault  simulation  to  greatly 
speed  the  process.  The  usefulness  of  this  approach  in  measuring  test  effectiveness 
depends  on  the  adequacy  of  the  models  (hardware  Item  model  and  fault  model)  to 
accurately  reflect  the  real-woiid  situation.  Modeling  must  be  achieved  at  a  level  of  detail 
that  allows  ail  known  and  statistically  significant  failure  modes  to  be  included. 

Although  commonly  anoepted,  the  application  of  these  measures  la  In  various 
stages  of  maturity,  based  upon  the  equipment  composition  (I.e.,  digital,  analog,  radio 
frequency  and/or  mechanical).  At  this  time,  the  application  experience  has  been 
concentrated  In  the  area  of  digital  Implementations.  However,  even  In  this  area, 
significant  additional  effort  will  be  required  In  order  to  relate  these  measures  to  operational 
performance.  The  degree  of  applloatlon  of  test  effectiveness  measurement  techniques  to 
the  remainder  of  the  listed  equipment  types  has  been  quite  limited  to  date.  IDSS,  the 
Navy's  Integrated  diagnostics  program,  has  recognized  this  need  and  has  an  active 
diagnostic  tool  development  program  underway.  One  of  these  tools,  the  Weapon  System 
Testability  Analyzer,  Is  structured  to  address  test  effectiveness  measursment,  as  well  as 
inherent  testability  assessment. 

Effective  and  realistic  fault  modeling  Is  a  key  element  In  the  development  of  the 
simulation  capability  needed  to  support  the  development  of  either  an  ATPQ  or  an 
automated  test  effectiveness  measurement  tool.  However,  It  Is  anticipated  that  no  single 
fault  model  and/or  simulator  will  be  applicable  to  the  broad  range  of  equipments  to  be 
employed  wHhln  a  complex  system;  therefore,  a  combination  of  models  will  be  required  to 
meet  the  requirement  for  automated  determination  of  fault  detection  and  Isolation  levels. 

For  False  Alarm  estimation,  a  proosdure  which  Is  documented  In  a  report 
(RADC‘TR‘87>S6)  entitled  "Predictors  of  Organizational  •  Level  Testability  Attributes* 
developed  prediction  equatlone  for  various  testability  related  parameters.  Rather  then  try 
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to  dtvtiop  tn  tquatlon  to  prtdiot  Faitt  Alarm  Rato  (FAR)  dlractly,  an  approach  was  takan 
to  predict  the  CND  rata  tinea  thia  paramatar  ahould  cloaaly  track  FAR.  The  following 
dataila  a  prediction  method  for  CND  rata.  Note  that  thIa  la  a  modal  baaed  on  empirical 
data  from  avionloa  equipment  of  the  mld<ig80'a  era  and,  aa  la  the  oaaa  with  all  modala, 
care  muat  be  taken  In  uaing  the  modal  for  new  technology  or  appllcatlona. 

The  aquation  for  CND  rata  followa; 

CND  RATE  -0.0028  0.375*FLRRATE 

+2.6  E-6TRANSIENT  ♦  6.0E-1 1  *TC7 

The  varlabla  FLRRATE  aooounta  for  the  LRU  Failure  Rata. 

The  variable  TRANSIENT  attampto  to  oharaotarlza  the  tendency  of  an  LRU  to 
exhibit  Intermittent  fallurea  reauiting  from  marginal  or  degracNng  oomponenta. 

The  variable  TC7  numerically  charaotertzea  the  likelihood  of  a  aneak  circuit 
exiating  in  an  LRU. 

TRANSIENT  -  (IC'a  +  2*RESISTORS  +  41  'RELAYS  +  2'CAF*ACITORS 

•  OTRANSiSTORS)/#  of  SRU*t 

TC7  •  INTERCONNBCTS*(IC’e  •  leO'REUYS 

•  060'SWITCHES  +  30*TRANSISTORS) 

Where; 

RELAYS  -  Total «  of  Reiaya  In  LRU. 

CAPACITORS  M  Total «  of  Capacitora  in  LRU. 

RESISTORS  ■  Total  #  of  Reaiatora.  both  fl.xed  and  variable,  In  LRU. 

TRANSISTORS  ■  Total  #  of  dlacrete  tranalatore,  including  FETa,  Bipolar,  etc.  that  are  In 
LRU  design. 

IC'a  ■  Total  #  of  Integrated  drouHa  In  LRU. 

SRU'a  •>  Total  #  of  SRU'a  that  oompoae  an  LRU. 

INTERCONNECTS  ■  Total  #  of  electrical  Intarconnecta  uaed  to  mate  SRU'a  to  the  boat 
LRU. 

SWITCHES  -  Total  #  of  awitohea  In  the  LRU  dealgn. 
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Sp«olfl08  about  tho  davalopmant  or  application  of  this  aquation,  or  tha  estimation  of  the 
Input  parameters  can  be  found  in  the  above  referenced  report. 
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Rl^gM9CTg,^ytTY. 

Maintaintblllty  Damonatratlona  art  parfortnad  In  aooordanoa  with  tha 
appropriata  damonatratlon  mathod  oontalnad  In  MIL*8TD>471A.  Notloa  2  of  MIL>STD* 
471 A  (USAF)  contains  raqulramants  for  damonatratlon  and  evaluation  of  aystam 
BIT/axtarnal  tast/fault  Isolatlon/tastabitity  attrlbutaa.  This  mathod  will  damonstrata  tha 
Integration  of  tha  diagnostic  capability  for  tha  system  (a.g.,  Integration  of  ambaddad  test 
software  and  hardware  techniques,  automatic  and  manual  tost,  BIT/SIT,  training  levels, 
human  Intorfacas).  Tha  Maintainability  Demonstrations  evaluate  tha  diagnostic 
performance  of  the  system  with  respect  to  tha  diagnostic  performance  criteria  and 
objaotlvas  established  In  aooordanoa  with  MIL>STD-470  (Maintainability  Program)  and 
MIL*STD>2165  (Testability  Program)  and  tha  requirements  for  on  Integrated  diagnostics 
capability  demonstration  oontalnad  In  tha  PSD  SOW. 

EBQfiepwnB 

Tha  Integrated  diagnostics  process  Increases  the  scope  of  maintainability 
demonstrations.  It  Is  tha  Contractor  Program  Manager's  responsibility  to  ensure  that  this 
Inoreased  scope  Is  understood  and  Implemented.  It  Is  the  designers  responsibility  to 
design  the  demonstration,  evaluate  the  results  snd  take  the  necessary  corrective  actions. 

The  scope  of  Maintainability  Demonstrations  Includes; 

1 .  Demonstration  of  Testability  Parameters 
>  BIT  PauH  Detection 
-  BIT  Isolation  Time 
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REQUIREMENT 


•  BIT  Fault  Isolation  Laval  (Ambiguity  Group) 

2.  Damonstratlon  of  Taat  Etfactivanass  (ATE)  (MIL‘STD-2077) 

•  ATE  Fault  Datectlon 

•  ATE  Fault  Isolation  Tima 

-  ATE  Fault  Isolation  Laval  (Ambiguity  Group) 

•  UUT/ATE  Compatibility 


3.  Damonstratlon  of  Tachnioal  Information 

•  Tachnioal  Information  Accass  Tima 

-  Tachnioal  Information  Ralativa  Accass  Easa 

-  Tachnioal  Information  Format 

•  Tachnioal  Information  Usability 

4.  Damonstratlon  of  Tralning/Skllls 

•  Ralatlonshlp  batwaan  maintananoa  prooaduras  and  skills 

•  Ralatlonshlp  batwaan  formal  training  and  actual  maintananoa  job 
flow. 

5.  Damonstratlon  of  Vartloal  and  Horizontal  Intagratlon 

•  Compatibility  and  Conslstaney  of  diagnostic  damonstratlon  rasults 
batwaan  maintananoa  lavals  and  among  thair  raspactlva  diagnostic 
alemants. 

QUIPANCl 

Unfortunataly,  tha  ability  to  carry  out  a  single  damonstratlon,  or  avan  a 
sarlas  of  damonstratlons,  to  prova/avaluata  this  laval  of  diagnostic  capability  Is 
dapandant  upon  having  all  of  tha  diagnostic  alamants  avallabla  for  tha 
maintainability  damonstratlon.  Whila  this  should  always  ba  tha  goal,  It  may  not  ba 
faaalbla  for  all  of  the  above  due  to  davalopmant  sohadulas,  UUT  design  Inatablllty, 
data  availability  and  other  overall  program  constraints.  (Note  that  this  Is  a  primary 
reason  for  a  Diagnostics  Maturation  Program.) 

Typically,  the  contractor  prepares  a  Maintainability  Demonstration  Plan 
early  In  tha  FSD  Phase  and  that  plan  Is  subject  to  government  review  and  approval. 
Tha  designer  should  taka  advantage  of  this  opportunity  to  design  tho  Maintainability 
Damonstratlons  to  Include  tha  factors  cited  above.  This  can  have  a  significant  cost- 
savings  Impact  on  tha  Diagnostics  Maturctlon  Program  raquiramants. 
Maintainability  Demonstrations  represent  tha  first  major  opportunity  to  evaluate  tha 
laval  of  diagnostic  capability  achieved.  AIsc,  Maintainability  Demonstrations  can  ba 
conducted  early  enough  to  Implement  corrective  action  cost-affactivaly. 
Demonstrations  are  conducted  while  the  system  is  still  considered  to  be  In  the 
Davalopmant  Phase.  After  tha  damonstratlons  are  completed,  tha  relative  cost  of 
identifying  deficiencies  and  implementing  corrective  action  Is  significantly  Increased. 
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REQUIREMENT  #4.2 


A  slonKIcant  milestone  of  'Government  Acceptance’  occurs  upon  satisfactory 
completion  of  Maintainability  Demons^rntlons.  After  this  milestone,  costs  for 
Identification  and  resolution  of  diagnostic  deficioncles  may  be  subject  to  contract 
interpretation  and/or  negotiation.  The  total  strategy  for  the  test  and  evaluation  of  the 
diagnostic  capability  Is  placed  on  the  TEMP,  and  detailed  In  the  Integrated  Test 
Plan. 


Based  upon  the  selected  scope  of  the  Maintainability  Demonstration, 
prooedures  from  MIL-STD-471  are  utilized  and  adapted  for  the  scope.  These 
procedures  are  documented  In  the  Maintainability  Demonstration  Plan.  The  results 
of  the  Maintainability  Demonstration  are  documented  In  a  technical  report  - 
Maintainability  Demonstration  Results. 

Concurrent  Demonetratlona 

The  overall  diagnostic  oapablllty  is  the  sum , of  a  variety  of  diagnostic 
elements.  Therefore,  a  requirement  stiould  be  established  for  early  demonstration 
of  the  entire  diagnostic  capability  produced  by  the  Integration  of  all  of  these 
diagnostic  elements.  This  Is  referred  to  as  concurrent  demonstrations,  where  the 
timing  of  various  diagnostic  element  demonstrations  are  planned  and  scheduled  for 
concurrency  so  that  the  Integrated  capability  can  be  assessed. 

Each  element  of  the  diagnostic  capability  must  be  demonstrated,  as  well 
as  the  result  of  the  combining  nr  Integration  cf  the  elements.  For  example,  a 
demonstration  of  subsystem  BIT  may  prove  fault  detection  and  Isolation  levels.  A 
demonstration  of  ATE  may  prove  external  fault  detection  and  isolation  levels.  A 
concurrent  demonstration  of  these  two  diagnostic  elements  will  prove  the  ability  of 
tho  ATE  to  use  BIT  circuitry,  to  use  BIT  results,  and  the  consistency  of  test  results 
between  BIT  and  ATE.  By  concurrent  demonstration,  the  whole  Is  greater  than  tho 
sum  of  the  parts.  A  significant  set  of  factors  reiated  to  the  result  of  the  integration  of 
the  diagnostic  elements  must  be  evaluated  eariy. 
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CHECKLIST 


Does  the  demonstration  plan  provide  a  \0Q%  fault 
coverage  capability  across  all  levels  of  maintenance? 

e  Organizational  Level 
e  Intermediate  Level 
e  Depot  Level 

E2f  Are  the  failure  modes  to  be  demonstrated  and  criteria 
to  be  utilized  adequately  specified  for  each  maintenance 
level?  Will  an  adequote  number  of  faults  be  inserted 
as  required  by  MIL-STD-471  to  statistlcolly  prove 
that  FD/FI  requirements  are  or  are  not  met? 

Ei  Is  the  demonstation  structured  to  provide  an 
evaluation  of  the  diagnostic  capabilities  as 
an  integrated  system' 

of  Do  the  subject  plans  demonstrote  an  integrated, 

cohesive  maintenance  flow  in  terms  of  demonstrating 
how  a  fault  would  be  detected  and  repaired?  Is  a 
systems  approach  to  the  maintenance  process  taken 
in  the  overall  approoch  to  demonstration  planning? 
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CONDUCTINQ  DESIGN  REVIEWS 
OVERVIEW 

During  the  acquisition  of  a  weapon  system  there 
are  at  least  eight  formal  technical  reviews  t  d 
audits,  which  may  be  conducted  by  the  contractor 
for  the  Government  Program  Manager.  As  in  the 
diagnostic  design  process,  there  Is  a  tendency  to 
conduct  separate  reviews  and  audits  based  upon 
the  function  being  addressed.  This  particularly 
refers  to  logistics,  reliability,  maintainability, 
testability,  human  engineering,  and  safety. 
Integration  of  these  reviews  and  audits  to  address 
diagnostic  Issues  Is  a  must.  MIL-STD«1521  Is  the 
prime  document  which  defines  the  Issues  to  be 
addressed  at  each  of  these  formal  reviews.  At 
present,  these  checklists  are  Inadequate  In  terms 
of  both  testability  and  diagnostics  and,  thus,  these 
reviews  and  audits  may  not  serve  their  purpose. 
Additional  guidance  must  be  given  to  both  the 
government  and  the  contractor  In  order  to  alleviate 
this  problem. 

Informal  reviews  are  often  required.  Guidance  for 
these  Informal  reviews  can  be  drawn  from  formal 
review  guidance. 


TESTABILITY/ 

DIAGNOSTICS 


— I  PROGRAMMATIC  | 
.  — j  REQUIREMENTS  [ 


— ^  DESIGN  I 


EVALUATION  | 


I  . I  MATURATION  | 


IMPORTANT  CONSIDERATIONS  TO  BE  ADDRESSED 

Rfanis. 

S.1  Technical  reviews  and  audits  must  address  all  facets  which  affect  the 
performance  of  the  diagnostic  capability. 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

PSD 

PROD/ 

DEPll 

WEAPON 

SYSTEM 

ACTMTIES 

ZS  AAA 

SCP  DCP  PREL  DETAIL  lOTItE 

DESIGN  DESIGN 

DIAGNOSTIC 

ACTIVITIES 

A  A A  AAA  A  A 

SRR  SDR  PDR  COR  TRR  PRR  FCA  PCA 

PIA<glHMl]fi.Ag]nyiTY 

T«ohnloal  rcvltwt  and  audits  art  an  important  factor  in  aaauring  that  tha 
govammant  is  fumiahad  with  a  waapon  ayatam  which  maata  Ka  raquiramanta. 

fRQQgPtiWB 

MIL  'STD-1621  liats  10  formai  taohnioai  raviawa  and  audits.  Of  thasa  10,  sight 
ara  conoidarad  orltloal  In  tha  aohlavamant  of  a  satisfactory  diagnostic  capability.  Tha 
following  guldanoa  aupplamanta  and  expands  tha  guidance  contained  In  MtLo3TD<1521. 
Technical  Raviawa  and  Audits  for  Systems,  Equipments,  and  Computer  Software. 

Although  design  reviews  ara  recognized  as  being  Important  to  verify  design 
before  production,  tha  lack  of  depth  In  these  reviews  is  alarming.  Tha  causa  of  these 
inadequate  reviews  must  be  shared  by  both  the  contractors  and  the  government. 
Contractually,  the  government  rarely  requires  the  contractor  to  do  a  oomprahenaive 
technical  review,  and  the  contractor  doss  not  do  so  unless  required,  even  though  It  may 
be  cost  effective  from  his  point  of  view.  Even  whan  tha  right  words  are  used,  tha  end 
results  depend  largely  on  corporate  policy  to  allocate  sufficient  reeources  to  perform  a 
detailed  analysis  of  the  design  and  associated  processes.  The  designer,  obviously,  has 
an  Important  input  to  these  reviews.  Therefore,  It  follows  that  he  must  understand  tha 
objectives  and  scope  of  these  reviews. 
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QUIDANCE 

Quidanct  ralating  to  thasa  various  raviaws  Is  contalnad  In  tha  appandicas  to 
MIL-STD-1S21 .  Bacausa  thasa  appandicas  do  not  addrass  all  aapaots  of  tastablllty  and 
diagnostics,  soma  supplamantal  Information  Is  Includad  In  tha  following  paragraphs. 

Systam  RaquIramanta  Ravlaw  (8RR) 

The  objaotiva  of  this  ravlaw  la  to  ascartain  tha  adaquaoy  of  tha  contractor’s 
afforta  In  defining  systam  raquiramants.  It  will  ba  conducted  whan  a  significant  portion  of 
the  systam  functional  raquiramants  has  bean  astabllshad. 

Tha  diagnostic  capability  ravlaw  portion  of  tha  SRR  will  analyze  tha  system 
Items  that  are  related  to  diagnostics.  Tha  following  Items  will  ba  reviewed,  as  appropriate: 

0  Mission  and  Raquiramants  Analysis 
0  Functional  Flow  Analysis 
0  Preliminary  Raquiramants  Allocation 
0  Systam/Cost  Effaotlvanass  Analysis 
0  Trade  Studies 
0  Synthesis 

0  Logistic  Support  Analysis 
0  Specialty  Olsclpllna  Studies 
0  Qanaratlon  of  Specifications 
0  Program  Risk  Analysis 
0  Integrated  Test  Planning 
0  Technical  Performance  Maasuramant  Planning 
0  Engineering  Integration 
0  Systam  Safety 
0  Human  Factors  Analysis 
0  Life  Cycle  Cost  Analysis 
0  Manpower  Raquiramants/Parsonnal  Analysis 
0  Milestone  Schedules. 

Tha  diagnostic  capability  ravlaw  should  addrass  tha  Impact  of  tha  results  of  tha 
Items  listed  above  on  tha  diagnostic  places  listed  below. 

0  Designad-ln  Reliability,  Prognostics,  and  Tastablllty 
0  Self-Test,  Built-In  Test,  Systam  Integrated  Test 
o  Support  Equipment,  Maintenance  Aids 
o  Technical  Data 
0  Personnel  Skill  Raquiramants 
0  Training  and  Training  Devices. 
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8yat«m  Dttign  Rtviaw  (SDR) 

This  r«vi«w  shall  bt  eonductad  to  avaluata  tht  optimization,  oorralatlon, 
oomplatanasa,  and  rlsKs  aasoolatad  with  tha  allooatad  taohnical  raquiramanta.  Also 
Inoludad  Is  a  summary  ravlaw  of  tha  systam  anginaaring  procaas  which  produead  tha 
allooatad  taohnical  raquiramanta  and  of  tha  anginaaring  planning  for  tha  naxt  phasa  of 
affort.  Basic  manufacturing  considarationa  will  ba  ravlawad,  and  planning  for  production 
anginaaring  In  subsaquant  phasas  will  ba  addraasad.  This  ravlaw  will  ba  eonductad  whan 
tha  systam  dafinitlon  affort  has  prooaadad  to  tha  point  whara  systam  oharactarlstics  ara 
dafinad  and  tha  Configuration  Itams  (Cl)  ara  Idantiflad. 

SpaoHIo  diagnostic  oonsidaratlons  ralata  to; 

0  Optimizing  tha  diagnostic  capability  (ohangas  aftar  Dam/Val  usually  ara  mora 
costly  and  tima  consuming) 

o  Praparatlon  of  a  Maturation  Plan 

0  Praparatlon  of  a  Systam  Spaolfloatlon  which  provides  a  capability  for 
addressing  100%  FD/FI  for  each  iaval  of  maintananoa 

0  Allocation  of  diagnostic  raquiramants  for  each  diagnostic,  alamant 

0  Ravlaw  of  tha  software  raquiramants  spaolfloatlon  to  assure  that  ambaddad 
diagnostic  software  considarationa  ara  Inoludad. 

Preliminary  Design  Ravlaw  (PDR) 

This  ravlaw  shall  ba  conducted  for  each  Configuration  Item  or  aggregate  of 
Configuration  Itama  to:  (1)  avaluata  tha  progress,  technical  adequacy,  and  risk  resolution 
(on  a  technical,  coat,  and  schedule  basis)  of  the  selected  design  approach;  (2)  determine 
Its  compatibility  with  parformanoa  and  anginaaring  specialty  raquiramants  of  tha  Hardware 
Configuration  Item  (HWCi)  development  spacifioatlon;  (3)  avaluata  the  degree  of  definition 
and  assess  tha  taohnical  risk  associated  with  tha  salaotad  manufacturing 
mathoda/prooassas;  and,  (4)  establish  tha  axistanoa  and  compatibility  of  tha  physical  and 
functional  Interfaces  among  tha  Configuration  item  and  other  Items  of  equipment,  facilities, 
computer  software,  and  personnel.  For  CSCIs,  this  review  will  focus  on:  (1)  tha 
evaluation  of  tha  progress,  consistency,  and  technical  adequacy  of  tha  salaotad  top«laval 
design  and  test  approach;  (2)  compatibility  between  software  raquiramants  and 
preliminary  design;  and,  (3)  on  tha  preliminary  version  of  tha  operation  and  support 
documents. 

In  addition,  tha  following  Kerns  In  the  diagnostic  area  should  ba  presented  at  tha 
appropriate  depth  for  ravlaw. 
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0  Prallmlnary  Failure  Modat  and  Effaota  Analyaia 

0  Dtaign  data  analysaa  for  BIT/SIT  intagratad  diagnottloa,  Including 
raquiramanta  and  praliminary  daalgn  vartflcation  raauHa 

0  Maintananoa  oonoapt  for  tha  portion  of  tha  ayatam  baing  ravlawad  and  Ita 
tracaability  to  tha  ayatam  maintananoa  oonoapt 

0  Oparatlonal  maintananoa  funotlona 

0  RaauHa  of  tha  analyaia  of  tha  Inharant  (intrtnalo)  taatabllHy  of  tha  praliminary 
daalgn 

0  Allocation  of  qualHatIva  and  quantHativa  raquiramanta 

0  CrHarla  for  a)(tamal  diagnoatic  atamanta 

0  Trada*off  atudlaa 

0  Coat/Syatam  Effaotivanaaa  Modaling  and  Ufa  Cyola  Coat  Analyaia 

0  Praliminary  Loglatio  Support  Analyaia.  Including  taaK  analyaia  and  ralatad 
paraonnal  and  aupport  aquipmant  information 

0  Evaluation  of  aHamatlvaa 

0  Taat  and  avaluatlon  plana. 

Critloal  Daalgn  Ravlaw  (CDR) 

Thia  ravlaw  ahall  ba  oonduotad  for  aaeh  Configuration  Ham  whan  data!!  daalgn  la 
aaaantlally  oomplata.  Tha  purpoaa  of  thIa  ravlaw  will  ba  to;  (1)  datarmlna  that  tha  datall 
doaign  of  tha  Configuration  Ham  undar  ravlaw  aatiaflaa  tha  parfomianoa  and  anginaaiing 
epaclalty  raquiramanta  of  tha  HWCI  davalopmant  apac  .loationa;  (2)  aatabliah  tha  datall 
daalgn  compatibility  among  tha  configuration  and  othar  Itama  of  aquipmant,  facllltlaa, 
computar  aoftwara  and  paraonnal;  (3)  aaaaaa  Configuration  Itam  rIaK  araaa  (on  a 
taohnical,  coat,  and  aohadula  baala);  (4)  aaaaaa  tha  raaulta  of  tha  produoibilHy  analyaaa 
oonduotad  on  ayatam  hardwara;  and,  (5)  ravlaw  tha  preliminary  hardware  product 
spaoificatlona.  For  CSC  la,  thia  ravlaw  will  focus  on  tha  determination  of  tha  acoaptablllty 
of  tha  detailed  daalgn,  parformanoa,  and  taat  charaotariatloa  of  tha  design  solution,  and  on 
tha  adequacy  of  tha  operation  and  support  documanta.  Tha  CDR  shall  ba  conducted  on 
each  Configuration  Itam  prior  to  fabricatlon/productlon/coding  ralaaaa  to  ensure  that  tha 
datall  design  solutions,  as  raflactad  in  tha  Draft  Hardwara  Product  Specification,  SoKwara 
Detail  Design  Document  (SDDO),  Data  Base  Design  Documant(s)  (DBDD),  Interface 
Design  Documant(8)  (IDD),  and  anginaaring  drawings,  satisfy  raquiramanta  astabliahad  by 
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by  tht  Hardwart  Davalopmant  Spaolfioatlon  and  Software  Top-Level  Deelgn  Document 
(STLOD).  The  CDR  ehall  be  held  after  the  Computer  Software  Operator's  Manual 
(CSOM),  Software  User's  Manual  (SUM).  Computer  System  Diagnostic  Manual  (CSDM), 
Software  Programmer's  Manual  (8PM),  and  Firmware  Support  Manual  (FSM)  have  been 
updated  or  newly  released. 

It  Is  desired  at  each  COR  to  provide  as  much  assurance  as  praotloable  that  all 
diagnostio  requirements  sre  satisfied:  I.  e.,  that  100%  diagnostic  oapablllty  will  exist  for 
eaoh  Cl  In  the  system.  While  it  probably  wilt  not  be  praotloable  to  certify  that  this  will  exist, 
the  following  data  should  be  presented  as  an  extension  of  the  Information  presented  at 
the  PDR. 

0  Detailed  fault  deteotlon/fault  Isolation  analyses  that  Identify  the  extent  to 
which  BIT/SIT  detect  and  isolate  faults  and  which  Identify  those  failures  that 
will  require  support  equipment  and/or  manual  methods  to  detect  and/or 
Isolate. 

0  Diagnostic  allocations  In  Part  11  Cl  specifloatlons  to  the  LRU  and  SRU  level. 
Traceability  of  these  requirements  to  the  Part  I  Cl  System  Specification 
should  be  demonstrated.  Note:  Flexibility  to  reallocate  diagnostic 
allocations  until  product  baseline  Is  established  at  PCA  should  be  provided 
wHNn  the  envek^  of  system  requirements. 

0  Definition  of  the  maintenance  plan/concept  for  the  Cl,  together  with 
supporting  L8A  documentation,  Including  supiMrt  requirement  and  level-of- 
repair  analysis  results.  Logistic  simulation  results  should  be  presented  to 
substantiate  the  plan/oonoept. 

0  Presentation  of  testability  anaiysis/assessment  results  for  the  Cl  design  to 
substantiate  the  fault  detection/  fauK  isolation  analysis. 

0  Early  program  failure  Identification,  prevention,  and  detection  analyses 
applicable  to  the  Cl  should  be  presented  to  sssist  In  verifying  diagnostic 
capability. 

0  Review  detailed  Maintainability  Demonstration  Plan  for  Inclusion  of 
diagnostio  capability  test  requirements 

0  Appropriate  updates  to  the  Items  reviewed  during  the  PDR. 

Teat  Reedineee  Review  (TRR) 

This  review  Is  conducted  for  each  CSCI  to  determine  whether  the  software  test 
procedures  are  complete  and  to  assure  that  the  contractor  is  prepared  for  formal  CSCI 
testing.  Software  test  procedures  are  evaluated  for  compliance  with  software  test  plans 


5-7 


CONDUCTINO  TECHNIGWS  AND  AUDITS 


REQUIREMENT  #5.1 


and  dtsorlptiona  and  for>  in  aooompllahino  taat  raquiramants.  At  TRR  tha 
oontraoting  aganoy  alto  ra«aulta  of  informal  aoftwara  taatlng  and  any  updataa  to 
tha  oparatlon  and  aupporti.  A  auooaaaful  TRR  ia  pradloatad  on  tha  oontraoting 
aganoy'a  datarminatlon  thivara  taat  proeaduraa  and  Informal  taat  raaulta  form  a 
aatlafaotory  baala  for  proeaformal  C8CI  taatlng. 

Tha  diagnoatic  a  tha  ayatam/CI  TRR(a)  ahall  ba  a  format  ravlaw  of  tha 
eontraotor'a  raadinaaa  to  kal  dlagnoatloa*ralatad  C8CI  taatlng.  It  la  oonduotad 
aftar  tha  aoftwara  taat  proca  avallabla  for  diagnoatioa-ralatad  C8CI,  auoh  aa  Cl 
BIT,  Syatam  BIT,  BIT,  atcar  oomputar  ayatam  oomponant  (C8C)  Intagratlon 
taatlng  la  oomplata. 

Tha  Itama  to  ba  noluda: 

1.  Raquiramant  •• 

Any  ohangaiSIT,  or  taatablilty  raquiramanta  oontalnad  In  tha 
ayatam/CI  Baquiramant  Bpaolfloatlon  or  Intarfaoa  Raquiramanta 
Spaolfloatton  not  baan  approvad  and  wNoh  Impact  C8CI  taatlng. 

2.  DaaIgnChani 

Any  ohangao  tha  BIT,  SIT,  or  taatablilty  daaign  paramatara 
oontalnad  In  ira  Top-Laval  Daaign  Doeumant  (8TLDD),  Boftwara 
Datall  Daaignrt  (SDDD),  Intarfaoa  Daaign  Dooumant(a)  (IDD)  alnoa 
tha  PDR  and  h  Impaot  C8CI  taatlng. 

3.  Softwara  Taatf  Daaorlptlona  - 

Any  ohangaaibaddad  diagnoatio  alamant  portion  of  tha  approvad 
Softwara  TaafP)  and  Softwara  Taat  Daaoriptlona  (STD). 

4.  Softwara  Taataa  •• 

Taat  prooaduuaad  In  conducting  BIT  and/or  SIT  taat  affactlvanaaa 
validation  aa  a  CSCI  taatlng,  including  rataat  proeaduraa  for  taat 
anomallaa  an«na. 

5.  Intagratlon  Ta  Proeaduraa,  and  RaauHa  •* 

Any  ambaddoatle  alamant  CSC  (a.  g.,  BIT  eomponanta,  SIT 
componanta)on  taat  eaaaa,  and  proeaduraa  uaad  In  conducting 
Informal  diagmant  CSC  Intagratlon  taata  and  tha  taat  raaulta. 
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6.  Softwar*  Tmt  RMOurott  •• 

Status  of  any  softwara  test  resources  that  are  required  specifically  for 
embedded  diagnostic  element  CSCI  testing.  Such  resources  may  Include 
diagnostic  test  personnel  and  supporting  test  software  and  materials, 
Including  software  test  tool  qualification  and  review  of  the  traceability 
between  requirements  and  their  associated  tests. 

7.  Test  Limitation 

Identification  of  all  software  test  limitations  associated  with  embedded 
diagnostic  element  CSCI/CSC  testing. 

8.  Software  Problems  - 

Summary  of  embedded  diagnostic  element  software  problem  status, 
Including  all  known  discrepancies  of  the  CSCI  and  test  support  software. 

9.  Schedules  - 

Schedules  for  the  remaining  embedded  diagnostic  element  software 
milestones. 

Production  Readiness  Review  (PRR) 

This  review  is  Intended  to  determine  the  status  of  completion  of  the  specific 
actions  which  must  be  satisfactorily  accomplished  prior  to  executing  a  production  go- 
ahead  decision.  The  review  Is  accomplished  in  an  incremental  fashion  during  the  Full- 
Scale  Development  Phase-usually  two  Initial  reviews  and  one  final  review,  to  assess  the 
risk  In  exercising  the  production  go-ahead  decision.  In  Its  earlier  stages,  the  PRR 
concerns  Itself  with  gross-level  manufacturing  concerns,  such  as  the  need  for  Identifying 
high-rlsk/low-yleld  manufacturing  processes  or  materials  or  the  requirement  for 
manufacturing  development  effort  to  satisfy  design  requirements.  The  reviews  become 
more  refined  as  the  design  matures,  dealing  with  such  oonoems  as  production  planning, 
facilities  allocation,  Incorporation  of  produoibllity-orlsnted  changes,  Identification  and 
fabrication  of  tools/test  equipment,  long-lead  Item  acquisition,  etc.  Timing  of  the 
Incremental  PRRs  Is  a  function  of  program  posture  and  Is  not  speollloally  looked  Into  other 
reviews.  The  diagnostic  consideration  concerns  the  use  ol  any  of  the  external  diagnostic 
elements  (e.g.,  ATE)  In  the  production  testing  environment. 

Functional  Configuration  Audit  (FCA) 

This  Is  a  formal  audit  to  validate  that  the  development  of  a  Configuration  Item 
has  been  completed  satisfactorily  and  that  the  Configuration  Item  has  achieved  the 
performance  and  functional  characteristics  specified  in  the  functional  or  allocated 
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configuration  idontlflcatlon.  In  addition,  tha  complatad  operation  and  support  documents 
shall  be  reviewed. 

The  FCA  Is  normally  conducted  on  a  prototype  or  preproduction  Item.  The  FCA 
validates  that  tho  Item  meets  its  specified  performance  requirements  and  Is  ready  for 
production  and  acceptance  Into  Air  Foroe  Inventory.  It  Is  Imperative  that  the  diagnostic 
capability  b^  validated  against  Its  specified  performance  requirements,  so  that  any 
diagnostic  capability  deficiencies  can  be  Identified  and  corrected  before  the  Item  proceeds 
Into  production  and  Is  then  deployed. 

Phyaloil  Configuration  Audit  (PCA) 

This  Is  a  teohnioal  examination  of  a  designated  Configuration  Item  to  verify  that 
the  Configuration  Item  *as  built*  conforms  to  the  technical  documentation  which  defines 
the  Configuration  Item. 

After  successful  completion  of  the  audit,  all  subsequent  changes  to  the 
diagnostic  elements  are  processed  by  an  engineering  change  action.  The  PCA  also 
determines  that  the  diagnostic  element  aooeptanoe  testing  preaoribed  by  the 
documentation  Is  adequate  for  aooeptanoe  of  the  production  units  by  quality  assurance 
activities.  The  procedures  for  conducting  a  PCA  are  contained  In  MIL'STD*1521. 
Appendix  H.  Sample  PCA  Certifloatlon  Attachment  Checklists  are  contained  In  MIL*8T0> 
1521,  Appendix  I. 
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CHECKLIST 


□f  Ar«  th«  dMlgntrt  Included  In  the  r«vl«wi  ond  audits 
so  th^  eon  chollsnga  ths  design  and  asssse  risks? 


of  Are  the  diagnostic  reviews  held  as  an  integral 
port  of  the  prime  system  review,  but  In  '  . 

a  timely  manner  that  oliows  change  (If  necessary) 
in  the  diagnostic  equipment  or  process? 


6«11 


Biflntti 

0.1  Providt  Input  to  tho  prtparatlon  of  an  Intagratod  Tast  Plan,  which 
Inoludaa  tha  raquiramanta  (or  a  Taat  and  Bvaluatlon  Master  Plan. 

0.2  Aaauro  that  formal  tast  and  avaluatlona  addraaa  tha  antira  diagnostic 
capability. 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACnVIDES 

zs  zs  zs  zs 

- - - ^  CDR 

CONTRACT 

AWARD 

DIAGNOSTIC 

ACTIVITIES 

ZS  TS  ZS 

TEMP  TEMP  TEMP 

UPDATE  UPDATE 

PiA.9NQ6Bfi.Afi.T!Y?n 

The  rtquircmtnti  for  dlagnottlot  tost  and  ovaluatlon  ara  Idantlflad,  lohadulad 
and  Intagratad  Into  tha  Tact  and  Evaluation  Maatar  Plan  (TEMP). 

PROCePURi 

Tha  TEMP  la  a  living  dooumant  normally  praparad  by  tha  Contractor  Program 
Manager.  Ita  preparation  goes  through  many  Itaratlona  aa  tha  program  procaada  through 
Concept  Exploration  Phaaa  studies,  Demonstration  and  Validation,  Full-Soala 
Davolopmant,and  Production.  With  each  Iteration,  plans  for  diagnostic  Test  and 
Evaluation  (T&E)  should  baooma  firmer,  batter  defined,  and  with  target  mileatona  dates 
attached. 


Because  test  and  evaluation  is  a  major  cost  and  schedule  driver,  adequate 
planning  Is  essential  long  before  It  starts.  Test  planning  between  subopntractors,  the 
prime  contractor,  and  the  government  should  start  with  program  Initiation.  To  ensure  a 
successful  Integrated  test  program,  close  coordination  Is  required  between  the 
govsrnmant,  the  prime  contractor,  and  all  suboontraotors.  Tha  designer  should 
understand  the  scope  and  methods  to  be  used  In  evaluating  the  product,  and  provide 
Inputs  to  the  TEMP,  which  promote  realism  In  these  tests. 
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PREPARATION  OF  THE  TEMP 
OUIDAHCI 

DoO  Directive  5000.3  requires  the  preparation  of  a  Test  and  Evaluation  Master 
Plan  (TEMP).  The  TEMP  is  a  broad  plan  relating  test  objectives  to  required  systOm 
oharactoristios  and  critical  issues,  and  is  a  top-level  document  used  at  major  mileetone 
revlevirs  to  assess  the  adequacy  of  planned  teat  and  evaluation.  At  minimum,  it  addresses 
both  Development  and  Operational  Test  and  Evaluation.  It  Is  important  that  as  much  as 
possible  of  the  diagnostic  capability  be  included  in  these  T&Es. 

Develupmental  Tent  and  Evaluation  (DTAE)  is  the  T&E  conducted  throughout 
various  phasea  of  the  acquisition  process.  This  will  ensure  the  acquisition  and  fielding  of 
an  effective  and  supportable  system  by  assisting  In  the  engineering  design  and 
development  and  verifying  attainment  of  technical  performance  specifications,  objectives 
and  supportab'llty. 

Developmental  Test  and  Evaluation  also  includes  T&E  of  components, 
subsystems,  preplanned  product  improvement  (P^l)  changes,  hardware-software 
Integration  and  related  software,  as  well  as  qualification  and  production  acceptance 
testing.  Test  and  evaluation  of  compatibility  and  interoperability  with  existing  or  planned 
equipment  or  systems  is  emphasized.  This  T&E  encompasses  the  use  of  models, 
simulations  and  testbeds,  as  well  as  prototypes  of  Full-Scale  Development  models  of  the 
system.  The  diagnostic  capability  associated  with  component,  assembly  and  subsystem 
DT&E  should  be  Included  In  these  T&E  activities. 

Qualification  Testing  Is  the  part  of  DT&E  which  variflas  the  design  and  the 
manufacturing  procsss  and  provides  a  baseline  for  subsequent  acceptance  tests.  This 
accomplishes  two  separate  functions: 

(1)  Preproduction  Quallflcetion  Tests  are  formal  contractual  tests  that  ensure 
design  integrity  over  the  specified  operational  and  environmental  range.  These  tests 
usually  use  prototype  or  preproduction  hardware  fabricated  to  the  proposed  production 
design  specifications  and  drawings.  Such  tests  include  contractual  reliability  and 
maintainability  demonstration  tests  required  prior  to  production  release.  At  a  minimum, 
embedded  diagnostics  capabilities  and  the  Interfaces  to  external  diagnostic  elements 
should  be  tested  and  evaluated  during  pruproduction  qualification  tests.  As  a  goal,  the 
capability  of  external  diagnostic  elements  should  also  be  tested  and  evaluated. 

(2)  Production  Qualification  Tests  ensure  the  effectiveness  of  the  manufacturing 
process,  equipment  and  procedures.  These  tests  are  conducted  on  a  sample  lot  taken  at 
random  from  the  first  production  lot,  and  are  repeated  as  the  process  or  design  Is  changed 
significantly,  and  when  a  second  or  alternate  source  Is  brought  on  line.  These  tests  are 
also  conducted  against  contractual  requirements.  The  utilization  of  diagnostic  resources 
in  the  manufacturing  process  and  the  requirement  for  capture  of  diagnostic  data  from  the 
manufacturing  process  should  be  evaluated  during  production  qualification  tasting. 


jSS ^ 
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The  completion  of  Preproduction  QuallflcatlPn  Teat  and  Evaluation  before 
Milestone  III  decisions  Is  essential  and  will  be  a  critical  factor  In  assessing  the  system's 
readiness  for  production. 

Operational  Test  and  Evaluation  (OT&E)  Is  the  field  test,  under  realistic 
dcnditions,  of  any  item  (or  key  component)  of  weapons,  equipment  or  munitions  for  the 
purpose  of  determining  the  effectiveness  and  suitability  for  use  in  combat  by  typical 
military  users;  and  the  evaluation  of  trie  results  of  such  tests.  Operational  testing  Is 
accomplished  In  an  environmerit  as  opersitlonally  realistic  as  possible.  The  entire 
diagnostic  capability  should  be  assessed  during  OT^E  as  well  as  the  Integration  of  the 
diagnostic  capability. 

The  T^MP  must  oleaviy  specify  development  and  operational  test  events. 
However,  OT&E  and  OT&E  are  not  necessarily  serial  phases  In  the  evolution  of  a  vveapon 
system.  During  critical  acquisition  cycle. transitions,  elements  of  pT&E  and  Ot&E  may  be 
combined  or  occur  in  parallel,  but  not  at  the  expense  of  either  development  or  operational 
test  realism  nor  before  sufficient  DT&E  can  reasonably  assure  that  the  system  is  toady  to 
enter  dedicated  operational  testing.  DT&E  may  continue  Into  the  Production  and 
Deployment  Phase,  along  with  OT&E,  to  address  system  enhancements,  correction  of 
deficiencies,  or  modifications.  In  all  cases,  test  planning  for  all  test  phases  must  be 
addressed  In  the  system  TEMP. 

Teet  and  evaluation  planning  Is  Initiated  at  the  inception  of  the  development 
process  to  ensure  adequate  planning,  programming  and  budgeting  of  test  resources  and 
to  facilitate  test  schedullnc  to  support  major  program  decision  milestones.  Reliability 
assurance  should  be  well  underway  before  the  initiation  of  system  performance  tests. 
System  deficiencies  must  be  addressed  through  a  dynamic,  welNdocumented,  and  tightly 
managed  test*analyze>fix  and  retest  program.  The  evaluation  of  embedded  diagnostic 
elements  should  be  injected  into  these  raliability  assurance  tests. 

A  TE.MP  Is  required  for  all  major  defense  acquisition  programs.  The  TEMP 
defines  and  Integrates  test  objectives,  critical  issues,  systems  characteristics, 
resporslbllitlas,  resources  and  schedules  for  test  and  evaluation.  Test  resource 
requirements  must  be  addressed  in  the  TEMP,  along  with  a  critical  analysis  of  any 
shortfalls  that  will  impede  the  full  test  and  evaluation  of  the  system.  The  need  for  and  th;> 
avallabllltv'  of  the  various  diagnostic  elements  which  make  up  the  diagnostic  capability  Is 
addresssd  In  the  TEMP.  Plans  to  correct  existing  or  anticipated  test  resource  limitations 
are  aleg  included,  as  Is  a  listing  uf  evaluation  criteria  delineating  critical  parameters 
permitting  continuous  oversight  and  independent  assessment. 

DoD  5000.3‘iVI*1  contains  the  guidelines  for  the  preparation  of  the  TEMP. 
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CHECKUST 

EST  Hava  T4eE  aotivittea  baan  raaliatloally  plannad  and 
achadulad  to  provtda  naadad  Information  on  tha 
parformonoa  of  tha  antira  dlognoatlo  oopoblllty? 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTIVITIES 

A - ►A 

DTdeE 

DIAGNOSTIC 

ACnVITIES 

A  . 

DIAGNOSTICS 

DTdeE 

Evtiuat*  diagnottiei  parformanot  eharaetariatlea  during  Davalopmant  Taat  and 
Evaluation  (OT&E)  aetivitlaa  In  ordtr  to  datarmina  diagnoatle  oapabiiHiaa  aohlavad  and  to 
Idantify  dafloianolaa  In  tha  diagnoatio  capability.  Dlagnoitloa  DT&E  ahould  alao  attand  to 
tha  capability  aohlavad  by  tha  Intagratlon  of  tha  various  planned  diagnoatio  alamanta 
(parformanoa  monitors,  BIT/SIT,  tasting  (automatic  and  manual),  maintananoa  aida, 
taohnioal  information  and  training  (sKlllj))  into  a  oomprahansiva,  oohasiva,  diagnostloa 
subayitam. 

PROCePURE 

Davalopmant  Test  and  Evaluation  la  tha  T&E  oonduotad  throughout  various 
phasas  of  tha  acquisition  process  to  ensure  tha  acquisition  and  fielding  of  an  affaotiva  and 
supportable  syatem  by  assisting  In  tha  enginaaring  design  and  davalopmant  and  verifying 
attainment  of  technical  porformanea  spacifleetlons,  ob)eotlv(:«  and  supportablllty. 

Development  Test  and  Evaluation  alao  Includes  T&E  of  oomponenta, 
subsystems  and  preplanned  product  Improvement  (P^l)  changes,  hardware*aoftware 
integration  and  related  software,  as  v/all  as  qualification  and  production  aoceptanoa 
testing.  Teat  and  evaluation  of  compatlblHty  and  Interoperability  with  existing  or  planned 
equipment  and  systems  Is  emphasized.  Development  Test  and  E«mluutlon  encompasses 
tho  use  of  models,  simulations,  and  testbeds,  as  well  as  prototypes  or  Full-Scale 
Development  models  of  the  system. 
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Th«  dMlgn«r  ihould  b«  as  tctlvaly  Involvad  In  diagnottloa  DT&E  to  a naurt  that 
valid  taata  ara  davlaad  and  parformad,  valid  raaulta  dooumantad,  and  valid  data 
aooumulatad  and  to  anaura  that  a  oloaad*loop  analytio  approach  la  uaad  to  pinpoint  and 
oorraot  diagnoatio  daflolanoiaa.  Tha  daaignar  ahould  anaura  that  avary  opportunity  la 
baing  takan  to  avaluata  dlagnoatloa*ralatad  paramatara.  Thia  may  Involva  a  wida  ranga  of 
taat  aotivltlaa,  Including  rallability  taata,  parformanoa  taata,  human  factor  taata,  ate. 
Baalcally  whanavar  a  ayatam,  aubayatam  or  oomponant  la  baing  oparatad.  It  la  aubjact  to  a 
fallura.  Tha  diagnoatloa  raquiramanta  aaaoolatad  with  daaling  with  tha  fallura  ahould  ba 
vlawad  aa  an  opportunity  to  aaaaaa  tha  diagnoatio  capability. 

Tha  thruat  of  tha  Intagratad  Diagnoatloa  Prooaaa  with  raapact  to  DT&E  la  to 
includa/lnjaot  diagnoatio  parformanoa  avaluatlon  into  tha  malnatraam  of  DT&E  aotivltlaa. 
ThIa  la  dona  auoh  that  diagnoatio  parformanoa  can  ba  avaluatad,  daflolanoiaa  pinpointad, 
and  oorraotiva  action  Implamantad  whila  tha  ayatam  la  atill  In  davalopmant. 

Tha  diagnoatloa  DT&E  effort  aaaiata  tha  diagnoatio  daaign  and  davalopmant 
prooaaa,  and  varlflaa  attainment  of  diagnoatio  taohnioal  parformanoa  apaolfloationa, 
raquiramanta.  and  ol^aotlvaa.  Aa  auoh,  It  la  an  integral  part  of  tha  weapon  ayatam  daaign 
prooaaa.  Through  tha  provlalon  of  diagnoatloa  DT&E  data,  there  la  a  faadbaok  raitaritiva 
loop  bao!>  Into  the  intagratad  diagnoatloa  aotivltlaa  In  prooaaa.  Including  tha  diagnoatio 
ayatam  engineering  anaiyala;  diagnoatio  riak  analyala;  alloeation  of  diagnoatio  goala; 
diagnoatio  tradaa  for  ayatam  optimixatlon;  diagnoatio  daaign  tradaa;  and,  tha  Idanttfloatlon 
and  parformanoa  of  diagnoatio  daaign  taaka.  Through  thia  methodology,  tha  diagnoatio 
daaign  la  oorraotad.  Improved,  or  updated,  and  ttia  diagnoatio  daaign  maturaa. 

Sufficient  diagnoatloa  DT&p  muat  ba  aooompllahad  before  tha  Mllaatona  III 
daolalon  to  proceed  to  production.  Thia  will  anaura  that  tha  major  apaolflad  diagnoatloa 
daaign  and  davalopmant  raquiramanta  for  tha  Fuii-Soala  Development  Phaaa  have  bean 
mat,  with  raapaot  to  parformanoa  raquiramanta  and  apaolfloationa  ountalnad  in  program 
dooumanta. 

Tha  aoopa  of  diagnoatloa  T&E  afiould  Include  fault  dataotbn,  iaolatlon  accuracy 
and  timallnaaa  provided  by  performance  monitoring,  BIT/SIT,  automatio  and  manual 
tatting,  taohnioal  Information  and  maintananoa  aida,  maintenance  procaduraa,  manpower, 
paraonnal  and  akill  lavala  at  tha  ayatam,  aubayatam,  LRU/LPM,  SRU  lavala  acroaa 
planned  maintananoa  eohalona  (Organizational,  Intarmadinta  and  Depot). 

• 

Any  deviation  from  thia  full  acopt  of  T&E  maana  that  full  contidanoa  oannot  ba 
aacribad  to  tho  planned  diagnoatic  capability. 

Tha  major  approachaa  cl  DT&E  for  diognoatloa  Include  aotiona  : 
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REQUIREMENT  #6.2 


0  To  proof  od  In  phatf  with  iht  systf  m  and  support  equlpma nt  da va lopmo nt, 
so  that  Built-In  Tast  (BIT)  is  tastad  and  avaluatad  ooncurrantly  with  systaiTi 
partormanoa;  BIT  and  Systam  Intagratlon  Tast  (SIT)  tastad  and  avaluatad 
ooncurrantly  with  subsystam  intagratlon  and  systam  tasting;  and,  systam 
Intagratlon  and  safaty  tasting  ara  conourrant  with  diagnostio  tasting  of  BIT 
and  SIT  faaturas. 

0  To  Implamant  with  tha  Oiagnostlos  Maturation  Program  so  that  daflolanclas, 
amblgultlas,  and  additional  fallura  modas  Idantiflad  during  DT&E  ara 
raoordad  In  a  timaly  mannar  to  ansura  tracaablllty  and  appropriata 
oorraotions  ara  mada  to  tha  Intagratad  diagnostic  prooaduras. 

0  To  avaluata  ambaddad  diagnostio  dasign  as  a  saparato  antity  in  ordar  to 
assura  that  It  has  baan  inoorporatad  adaquataly  as  part  of  tha  systam 
dasign. 

0  To  avaluata  for  100%  diagnostio  capability  In  salactad  critical  araas  of 
systam  dasign  using  fault  avaluatlon, 

0  To  analyze  tha  systam  dasign  hlararohy  of  tast  tolaranoaa  (a.g.,  batwaan 
systam  BIT  and  LRU  and  SRU-iaval  BIT)  In  ordar  to  mlnimiza  falsa  alarms. 

0  To  oomplata  faasiblllty  DT&E  on  prototype  and  praproduotlon  units  In  ordar 
to  aasass  taohnioal  rIaKs  and  develop  s^utlons  to  remedy  daflolanolas. 

During  PSD,  spaolflo  diagnostic  capability  sagmanta  of  DT&E  afforta  Include  tha 
following  raqulramanta: 

0  Whan  available,  ATE  shall  be  avaluatad  for  initial  use  supporting  build  and 
ohaok-out  of  systems.  Manual  prooaduras  and  assooiatad  operational 
prototypes  shall  be  davalopad  for  support  of  tast  aotivltlas. 

0  Engineering  avaluatlon  of  tha  diagnostic  alamants  capability  at  subsystam 
and  systam  levels  shall  be  oonduotad  in  concert  with  systam  Intagratlon 
tasting  activities.  Including  evaluation  tests  in  tha  anginaaring  laboratory  and 
systam  Intagratlon  teat  faollitiaa. 

0  Effaotiva  development  of  a  diagnostic  capability  raqulraa  that  tasting  of 
diagnostic  oapabllltiaa  prooaad  ooncurrantly  with  prime  and  support 
equipment  development  in  an  orderly  and  planned  tima-phasad  mannar. 
Tha  object  of  tha  following  diagnostics  tasting  approach  is  to  provide  a  viable 
Organizational*  and  Intarmadlata-laval  diagnostic  capability  for  use  in 
support  of  flight  and  operational  tasting  activities  to  provide  for  early 
maturation  of  tha  diagnostic  capability.  It  should  also  be  a  program  objaotlva 
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to  villdato  tht  diagnottlo  oapablllty,  m  woII  us  Initial  rallabltlty  and 
maintainability  raquiramanta  bafora  promotion. 

0  During  aarty  aquipmant  davalopmant  taata,  bullt*ln  taat  faaturaa  should  ba 
taitad  and  avaluatad  oonourrantly  wHh  aquipmant  parformanoa  tasting.  BIT 
parformanoa  Is  just  as  assantlal  to  ovarall  waapon  systam  parformanoa  aa 
tha  usually  amphasizad  aspaots  of  aquipmant  parformanoa.  SImulatad 
aquipmant  falluras  should  ba  usad  to  assist  In  BIT  tasting  and  avaluatlon. 

o  Aa  aquipmant  prograssas  to  subaystam  Intagratlon  and  parformanoa  tasting, 
BIT  and  Systam  Intagratad  Taat  (SIT)  faaturas  should  ba  oonourrantly 
tastad,  avaluatad,  and  oorraotad.  SImulatad  or  amulatad  aquipmant  falluraa 
should  again  ba  usad  for  BIT/SIT  tasting  and  avaluatlon. 

0  Systam  Intagratlon  and  safa-tor*fiight  tasting  of  aquipmant  should  Ineluda 
dlagnoatio  tasting  of  BIT  and  SIT  faaturaa  to  aasura  raadlnass  of  this 
oapablllty  for  Flight  Tast  Support.  Conourrantly,  Organizatlonal-laval  support 
aquipmant  raquirad  for  diagnostio  support  should  ba  tastad  to  anabla  Its  usa 
In  tha  tast  program,  togathar  with  Prallmlnary  Malntananoa  Manuals  for 
Initial  Oparatlonal  Tast  and  Evaluation.  Simulator  of  aquipmant  falluras  to 
avaluata  dlagnoatio  oapabllHIas  should  ba  Includad  In  this  tasting  affort. 

0  Quallfloatlon  tasting  of  both  prims  and  support  aquipmant  shall  Ineluda 
validation  of  diagnostio  oapablllty,  which  Is  a  raquirad  aspsot  of  both 
aquipmant  and  systam  parformanoa.  SImulatad  aquipmant  falluras  should 
ba  Inoludad  in  tha  diagnostic  validation  tast  program.  Evaluation  of  BIT/SIT 
should  also  ba  oonductad  during  anvlronmantal  axtrama  tasting  of  tha  prims 
aquipmant  and  support  aquipmant,  to  assura  Its  propar  functioning 
throughout  tha  raquirad  aquipmant  parformanoa  anvalopa. 
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CHECKUST 

Sif  Do«t  the  Integrated  Test  Plan  provide  adequate 

detail  eoneernlng  epeelfle  TdeE  proeeduree.  data  baeee, 
modeitt  test  orticlee  and  acope  of  teetlng? 

S/  Have  critical  or  high  riek  Itema  related  to  diagnoetic 
capability  been  identified  and  highlighted? 

of  Are  the  neceeeory  teet  erticlee  available  to 
conduct  realietic,  timely  teats? 


QT  Haa 


Haa  every  opportunity  to  evaiuc 
DTd£  aetivltfee  been  identified? 


to  evaluate  dlagnoetica  during 
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WEAPON 
SYSTEM 
ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTMTIES 

IOT*E  FOTftE 

DIAGNOSTIC 

ACnVITIES 

A  A 

DIAGNOSTICS 

OTftE 

PIAAMOftTlC  AOTlYin 

Olaonoitio  ptrforminot  oharaettrlitloi  must  ba  avaluatad  In  a  ra alittio 
oparatlonal  anvironmant  during  Oparatlonal  Taat  and  Evaluation  (OT6E)  aotivltlaa  In  ordar 
to  datarmlna  diagnoatio  oapabllltlaa  aohlavad  and  to  Idantify  daflolanelaa  In  tha  diagnoatio 
capability.  Olagnoatloa  OT&E  ahould  fooua  on  tha  capability  aohlavad  by  tha  Intagration  of 
tha  varloua  plannad  diagnostic  alamants  Into  a  comprahansiva,  oohaalva  diagnostics 
subsystam. 


Oparatlonal  Tast  and  Evaluation  (OTAE)  la  tha  flald  tast,  undar  raallstio 
oondHIona,  for  tha  purposa  of  datarmlning  tha  affaotlvanaas  and  suitability  of  tha  systam  or 
aquipmant  for  usa  In  combat  by  typical  military  usars;  and  tha  avaluatlon  of  tha  rasults  of 
such  tasts. 

aMiPAMSi 

Oparationat  Taat  and  Evaluation  (OT&E)  aotivltlaa  Includa  Initial  OT&E  (lOT&E) 
and  Follow'on  OT&E  (FOT&E).  Tha  rasults  of  DT&E  aotivltlaa  should  ba  analyzad  by  tha 
Contractor  Program  Managar  with  halp  from  tha  daaignar  to  ansura  oonslstanoy  and 
continuity  of  T&E  aotivltlaa.  Oparatlonal  Tast  and  Evaluation  (OT&E)  must  ba 
aocompllshad  by  a  aaparata  govarnmant  facility  prior  to  tha  Mllastona  III  dacislon. 
Diagnostics  OT&E  Is  parformad  to  provida  a  valid  astimata  of  tha  oparatlonal  affaotlva nass 
and  suitability  of  tha  systam’a  Intagratad  diagnostics  dasign  and  prooaduras  using  tast 
Itams  sufflolantly  raprasantativa  of  tha  axpaotad  production  Hams. 


6-15 


OPERATIONAL  TEST  AND  EVALUATION 


REQUIREMENT  |6.3 


Major  approaohat  to  dlagnoatloa  OT&E  includa: 

0  Tatting  in  an  anvlronmant  at  oparationally  raalittio  at  poitibit 

0  OTAE  Initlattd  at  aarly  at  poatibla  during  tha  PSD  Phata 

0  Tatting  for  adharanoa  to  ovarall  OT&E  objaotivat,  with  raipaot  to  dlagnoatloa 

0  Continuad  coordination  with  tha  DIagnoatlot  Maturation  Program 

0  Evaluation  for  1 00%  diagnottio  capability  In  talactad  crHical  araaa 

0  Raiidom  diagnottict  tatting  in  nonoritioal  araat 

0  Furthar  anaiytit  of  tatt  tolaranoat  ralatad  to  tha  ayttam  hlararohy  and 
ambaddad/axtamal  diagnoatic  prooadurat  In  ordar  to  fninimiza  falia  alarmt. 

Tatting  (particularly  oparational  taata)  and  data  ooilactlon  ahould  fooui  on  tha 
dlagnoatloa  raquirarhantt.  Totting  and  data  ooitaotion  thould  alto  avaiuatc  tha  tpaolflad 
paramatara;  namaly,  Idantifloatton  of  orftioal  failurat,  tha  faita  alarm  rata,  tha  paroantaga  of 
fauitt  dataotad  and  Itolatad  automatloally  or  manually,  aaaooiatad  rapair  timaa,  tha 
unnaotttary  ramoval  rata,  oonalitanoy  of  tatt  raauitt,  and  tha  adaquaoy  of  partonnal 
tKlllt  oontidaring  all  maintananoa  Inoidantt. 

During  OT&E,  tyitam  parformanca,  oparational  aultabllity  and  aupportablllty 
faoiort  ara  avaluatad  in  an  oparationally  raalittio  anvlronmant.  Thtra  ara  two  typat  of 
information  that  can  ba  obtalnad  for  DIagnoatlot  T&E:  1)  ftuitt  within  tha  lyttam  and  how 
thota  faulta  wara  Idontifiad  (dlagnotad);  and,*  2)  fauKt/daflolandat  within  tha  diagnoitio 
capability.  For  tha  lattar,  thli  Inoludaa  avaluatlon  of  aaoh  alamant  which  oontributaa  to  tha 
total  diagnoatic  capability,  at  wall  at  tha  capability,  aohlavad  by  Intagration  of  tha 
dlagnoatloa  alamtntt.  Foouaad,  datailad  T&E  aotivltlaa  ditouaatd  in  Raquirtmtnt  #  6.2 
thould  ba  continuad.  Tha  formar  typa  of  data  can  ba  obtalnad  at  a  raault  of  Rtllabllity 
Growth  Tatting.  Tha  following  tpaolflo  Information  ahould  ba  avaluatad  for  aaoh  fault 
occurrtnca. 

1 .  How  did  tha  fallurt  manifaat  Ittalf? 

2.  Was  tha  manlfaatatlon  du#  to  ttratting  of  tha  tyitam  bayond  normal 
oparational  llmita? 

3.  If  a  BIT  alarm  occurrad,  was  It  tha  ratuH  of  a  confirmed  failure? 

4.  What  ttchniquas  wart  utad  to  Isolata  tha  fault? 
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6.  How  long  did  fault  Isolation  taka  using  those  techniques? 

6.  Was  the  failure  mission  or  operation  critical? 

7.  Was  It  a  new  or  unplanned  failure  mode?  Was  BIT  supposed  to  detect  the 
failure?  Old  It? 

8.  la  this  failure  mode  expected  to  be  encountered  In  the  operational  system? 

9.  Should  provisions  be  Included  In  the  diagnostic  capability  to  deal  with  this 
failure  mode? 

10.  Will  this  Involve  a  modifloatlon/additlon  to  BIT?  ATE?  Manual  Test 
Equipment?  Maintenance  Procedures?  Skill  Levels?  Technical  Data? 
Maintenance  Aids? 

11.  Is  an  ECP  required? 

12.  Is  further  investigation  required? 

If  yes  •  What  plans  have  been  made? 

If  no  •  Why  not?  (brief  description) 

13.  Is  correction  of  the  diagnostic  deficiency  part  of  contractual  requirements? 
Tied  to  Incentive  or  warranty  provisions? 


I 

I 

i 

I 
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CHECmST 

ESf  It  th«  d«tign«r  giving  adequatt  lupport  to  OTdeE 
activltlos? 


MATURATION 


REQUIREMENT  #7 


MATURATION  OP  THE  DIAQN08TIC  CAPABILITY 


QYBHyiBW 

HIstorioclly,  oft«ri «  weapon  system's  diagnostic 
capability  does  not  meet  Its  performance 
requirements  prior  to  deployment.  The  basic 
reason  for  this  Is  that  all  faults  cannot  be  predicted 
and,  thus,  adjustment  of  the  diagnostic  capability 
Is  required  during  the  first  few  years  after 
deployment.  Escentlally,  this  requires  a  well* 
planned  maturation  period,  which  allows  for  the 
growth  of  the  diagnostic  capability.  Closely 
coupled  with  this  maturation  Is  the  requirement  for 
collection  and  analysis  of  data  relating  to  the 
performance  of  this  diagnostic  capability,  both  In 
ths  field  and  In  the  factory.  Care  muet  be 
exercised  by  both  the  government  and  the 
contractor  to  assure  that  proper  and  detailed  data 
Is  collected.  Early  planning  for  this  maturation 
period  Is  a  must. 


TESTABILITY/ 

DIAGNOSTICS 


PROGRAMMATIC  | 

DESIGN  1 

ASSESSMENT  | 

REVIEWS  1 

evaluation  I 

*  1 

MATURATION  | 

7.1  A  detailed  DIagnoetloe  Maturation  Plan  neede  to  be  prepared  early  In  the 
acquisition  prooeaa. 

7.2  A  diagnoello  data  oolleotlon  and  analysis  aystem  must  be  wstabllshed  to 
provide  for  eorreetive  measures. 
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WEAPON 

SYSTEM 

ACQ.  PHASE 

OPER. 

REQMTS. 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

DEPL 

WEAPON 

SYSTEM 

ACTMTIES 

ZS  71 

SYSTEM  PDR 

SPEC. 

DIAGNOSTIC 

ACTMTIES 

A  A 

PLAN  UPDATE 

Mott  dlagnoftlo  tmplt mtntatloni,  no  matttr  how  w«ll  oonooivtd,  raqulrt  a 
parlod  of  tima  for  Ida ntlfloation  of  probiama  and  eorraotiva  action  to  raaoh  tpaoiflad 
patformanoa  lavala.  Thit  raquiramant  It  aatabllthad  In  ordar  to  formallza  tha  diagnottlot 
maturation  and  to  allow  tha  maturation  to  ba  Initiated  aarly  In  tha  tatt  and  avaluatlon 
prooatt.  ThIt  raquiramant  la  initlatad  aarly  to  that  aarly  Idantifloatlon,  tracking,  and 
oorraotlon  of  dlagnottlo  probiama  art  aohiavad.  Tha  planning  for  thit  activity  It  formallzad 
by  tha  davalopmant  of  a  DIagnoatIo  Maturation  Flan  or  othar  appropriata  dooumant. 

PWOCroURB 

Whila  It  It  tha  Contractor  Program  Managart  raapbntlblllty  to  prapara  tha 
Dlagnottlo  Maturation  Plan,  tha  datlgnar  thould  undarttand  tha  toopo  and  mathoda  to  ba 
utad  In  maturing  tha  dlagnottlo  capability  to  attura  adaquata  eorraotiva  aotlona  are 
plannad  and  Implamantad. 

Tha  Contractor  Program  Manager  mutt  anaura  that  tha  plan  It: 

1.  Comprahanalva 

0  Aoroat  all  dlagnottlo  alamantt 
0  Inoludaa  tha  Integration  of  tha  alamantt 


2.  Timely 
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0  Is  Initiattd  ttarly  \o  plan  for  the  requirad  rasourcaa  and  Implamant 
eorractiva  actions 

0  Maturation  Is  completed  by  Milestone  IV,  per  DoD>ln8tructlon-5000.2 

3.  Coordinated 

0  Includes  coordinated  actl'/itiM  from  ilie  "IIKIes* 

0  Utlllzsa  standard  data  collection  syjtams 

4,  Cost  Ezffectivo 

0  Allows  data  collection  to  be  transferable  and  usable  by  government  (i.e., 
DT&E  and  production  test  data). 


QUIDANCE 

A  program  to  mature  the  diagnostic  capability  should  be  planned  for  tho  early 
fielded  production  syatema.  A  one>to*three-year  maturation  program  should  be  planned 
for  complex  weapon  systems  with  extensive  automatic  testing  capability.  For  major 
weapon  systems,  the  coordination  with  Milestone  IV,  Logistic  Readiness  and  Support 
Review  (OoD<ln8truotlon*6000.2)  Is  essential.  This  program  should  include  provisions  for 
on-sIte  collection  of  diagnostic  performance  data,  with  engineering  follow-up  to  provide 
corrective  actions. 

The  plan  should  define  an  approach  and  methodology  to  assure  that  as 
dtf.velopment,  test  and  evaluation,  and  early  operational  use  of  the  system  progress, 
problems  presented  by  new  failure  modes,  test  voids,  ambiguities,  and  test  tolerance 
difficulties  are  recognized  and  defined,  and  thel'  solutions  are  traceable  to  diagnostic 
software  and  manual  procedure  updates.  The  plan  should  recognize  that  such 
occurrences  are  expected  and  normal  and,  therefore,  should  concentrate  on  problem 
recognition,  definition,  and  correction,  with  appropriate  tracking  for  traceability. 

The  approach  and  methodology  defined  should  recognize  that  a  basic  element 
of  the  Integrated  diagnostics  concept  Is  Identification  of  the  set  of  faults  which  are  known 
or  expected  to  occur.  The  methodology  shall  provide  for  definition  of  this  set.  initially 
through  Failure  Modes  and  Effects  Analysis.  Testability  Analysis,  and  other  tools  and 
experience.  Provision  for  growth  of  this  set.  as  new  failure  modes  are  encountered  during 
testing  and  deployment,  should  be  incorporated  In  the  plan,  together  with  explicit  criteria 
to  be  used  In  deciding  whether  or  not  a  newly  encountered  fault  shall  be  added  to  the  set 
of  faults  for  which  explicit  olagnostic  procedures  (as  opposed  to  more  general 
procedures)  are  provided  for  detection  and  isolation  of  tho  fault.  The  life  cvcie  cost 
effectiveness  of  adding  explicit  diagnostic  procedures  for  the  newly  encoun;<«red  fault 
shall  be  one  factor  considered  In  the  decision. 
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Th»  plan  should  provide  for  an  orderly  development  and  maturation  prooese  for, 
diagnostic  software  and  manual  procedures  throughout  the  development,  test  and 
evaluation,  and  early  operational  use  time  periods  of  the  weapon  system  and  Its 
subsystems.  Methodology  to  assure  timely  and  continuing  technical  support  for  this 
maturation  process  by  both  conttactor  and  government  activities,  with  a  minimum  of 
administrative  delays,  should  be  a  feature  of  the  plan.  Orderly  transition  of  technical 
responsibilities  from  the  contractor  to  the  government  should  also  be  addressed. 

The  plan  should  present  milestones  to  be  met.  This  will  assure  that  the  final 
system  achieves  the  required  degree  of  diagnostic  capability.  The  plan  shall  show  the 
time  phasing  of  each  task  and  Its  interrelationship  with  other  tasks,  it  should  Identify 
required  data  review,  verification,  and  utilization  to  accomplish  the  required  tasks  and  to 
report  progress,  problems,  and  tradeoffs.  The  plan  should  assure  the  proper 
Implementation  of  diagnostic  design  features  by  designers  and  subcontractors. 

During  the  Dem/Val  Phase,  maturation  planning.  Is  centered  on  preliminary 
planning  for  data  collection,  analysis  and  coordination  with  similar  requirements  for 
reliability,  maintainability,  logistics,  data  collection,  analysis  systems,  etc.  Speolfloally,  this 
planning  shoutJ  Identify  potential  data  sources,  such  as; 

0  Laboratory  testing 
o  Developrnental  testing 
0  Operational  tsst  and  evaluation 
0  Acceptance  testing 
0  Preproduction  testing 
0  Production  testing 
0  Operation. 
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CHECKUST 

^  Do«s  thf  Diagnostics  Maturation  Plan  tncluds  a  stratsgy 
for  the  coilsetlon  of  diagnostic  performance  data 
through  DT&E,  OT4leE.  Production,  Initial  Operational 
Use,  and  Deployment? 

GST  Is  the  diagnostic  data  collection  plan  In  sufficient 
depth  to  allow  adequate  evaluation  of  dlognsotlc 
capability? 

S/  Does  the  plan  Include  provisions  for  all  diagnostic 
elements  embedded  and  e>cternal  — 
as  wdll  os  the  Integration  of  the  diagnostic  elements? 

ESf  Is  the  Integration  or  the  diagnostic  elements  planned 
for  early  enough  to  allow  evaluation  ond  cost-effective 
corrective  action  (e.g.,  prior  to  production  go-ahead)? 

Does  Maturation  Planning  Include  provisions  for  both: 

1.  Adequacy  of  the  dlognostlc  elements,  with  respect 
to  the  specified  allocated  copoblllty,  and 

2.  Unplanned  failure  modes,  which  may  arise  throughout 


DATA  COLLECTION  AND  FEEDBACK  REQUIREMENT  #7.2 


WEAPON 

SYSTEM 

ACQ.  PHASE 

CONCEPT 

EXPLOR. 

DEM/ 

VAL 

FSD 

PROD/ 

OEPL 

WEAPON 

SYSTEM 

ACTIVITY 

ZS  ZS  ZS 

SYSTEM  PRODUCT  ECP 

FABRICATION  BASEUNE 

DIAONOSnC 

ACnVITIES 

A  A  A  A  A 

DTIcC  lOTJtE  fOTM  DATA  OOSK 

ooL-  mpoim; 

uonoN  AonoN 

piAQHOftTig-Aiznyin 

Data  ralating  to  tha  parformanot  and  affaotlvanass  of  tha  diagnoatio  capability 
must  ba  oollaotad  during  davalopmant,  production,  and  oparatlon.  This  data  Is  usad  as 
tha  basis  for  tha  avaluatlon  of  diagnostics  and  for  tha  oorraotlon  of  daflolanolas. 

Tha  Kay  thrust  of  this  aotivlty  is  dafinitlon  of  appropriata  data  to  ba  oollaotad, 
maximum  usa  of  data  oollaotad,  coordination  of  data  oollaotlon  systams,  and  a  struoturad 
approach  to  oorraotiva  action. 

PROCBPURB 

Tha  Contractor  Program  Manager  is  rasponslbla  for  tha  Implamantatlon  of 
diagnostic  data  oollaotlon  and  faadbaoK  raquiramants.  This  Inoludaa  davalopmant  and 
Implamantatlon  of  a  oradlo-to*grava  aystam  for  both  contractor  and  govammant  uaa.  It  Is 
tha  design  Vb  job  to  maKa  sura  thaaa  design  oorractions  are  Implemantad, 

Tha  earlier  diagnostic  performance  daflolanolas  are  idantiflad,  tha  sooner  a 
more  oost*affaotlva  solution  can  ba  Implemantad.  Tharafora,  diagnostic  data  oollaotlon 
and  faadbaoK  is  Initiated  early  In  tha  teat  and  avaluatlon  process,  continues  through 
production  teat,  and  extends  Into  the  operational  environment.  Throughout  these  phases, 
different  types  of  data  are  collaotad,  different  data  collection  procedures  and 
mathodologlaa  are  used,  and  different  types  of  analysis  technique  are  conducted. 
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QUIPANCB 

Th«rt  art  no  atandird  n.athoda  for  data  oollaotlon  and  anatyala.  At  Indloatod 
undar  Raquiramant  #7.1,  Maturation  Planning,  tha  oollaotlon  of  thia  typo  of  data  la 
controlltd  by  a  numbar  of  military  atandarda.  Tha  raquiramanta  for  tha  atandarda  whioh 
daal  with  logiatloa,  rallablllty,  maintainability,  taatabillty,  human  anginaaring,  and  aafaty 
ovarlap  on#  anothar  (many  timaa  data  raqulrad  by  ona  may,  Indaad,  ba  raquirad  by  tha 
othar(a)).  Thua  oloaa  coordination  among  thaaa  varloua  data  raquiramanta  Is  naadad,  A 
aingla  data  baaa  la  daalrabia.  Soma  toola  ara  availabla  to  assist  In  tha  faadbaok  and 
analytia  task.  Thaaa  daiortptiona  ara  containad  In  Appandix  C. 

Tha  data  oollaotlon  prooadurat  oloaaiy  follow  tha  taat  and  avaluatlon  functions. 
As  axplalnad  In  DoD  Diraotiva  5000.3,  Taat  and  Evaluation,  tha  tima  parloda  and 
aaquanoaa  for  Davalopmant  Taat  and  Evaluation  and  Oparatlonai  Taat  and  Evaluation 
vary  from  pragram-to^rogram.  Thay  can  ovarlap  and  avan  ba  dona  aa  a  oomblnad  taat 
and  avaluatlon.  Thus  thara  ara  no  standard  guidallnas  that  apaoHy  tha  axaot  points  in  tha 
waaoon  ayatam  acquisition  phasa  whara  data  is  to  ba  oollactad.  Tha  syatam  must  ba 
flaxibla  to  Inoorporata  data  m  data  is  ganaratad. 

Tha  Contractor  Program  Manager  should  anaura  that  tha  proper  data  is 
oollaotad  and  that  oorractlva  actions  ara  pursued.  It  Is  tha  Job  of  tha  designer  to  make 
these  oorraotlons.  Cara  must  ba  taken  to  oollaot  only  that  data  raqulrad  to  assure  that 
tha  dlagncatlc  oapabllltlas  ara  performing  as  raquirad.  Automated  data  oollaotlon  syatams 
can  ba  employed.  Usually  thaaa  ara  more  affaotiva,  as  thay  ara  lass  dependant  on 
human  motlva^n  to  supply  the  raqulrad  information. 

Corraotlva  analysis  and  actions  should  ba  In  a  olosad-loop  system,  so  that  each 
daflolanoy  Identified  remains  an  open  Item  until  It  Is  formally  dooumantad  as  being 
oorractad. 


Tha  data  oollaotlon  and  faadbaok  system  should  ba  designed  so  that  spaolflo 
Information  Is  oollaotad  on  tha  parformanoa  of  tha  entire  diagnostic  capability,  as  wall  as 
for  each  of  tha  diagnostic  alamants  that  make  up  tha  diagnostic  capability.  Tha 
Information  must  ba  oollaotad  In  quantitative  form.  If  possible,  and  related  to  System 
Spaoifloatlon  raquiramanta.  Thus  tha  following  guidelines  on  tha  type  of  data  to  ba 
oollaotad  need  to  ba  tailored  so  that  tha  Information  can  ba  related  to  System 
Specification  raquiramanta  and  so  that  It  Is  clearly  apparent  who  la  to  supply  tha 
Information  and  whan  this  Information  Is  to  ba  supplied.  Examples  of  tha  type  of  data  to 
ba  collaoiad  follow. 
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Diagnostic  Data  Pacdbaek 

0  Effactivansss  and  afflclancy  of  aach  diagnostic  alamant 

0  Effaotivanaaa  and  afflclancy  of  tha  diagnostic  alamants  as  an  Intagratad 

aystam 

0  Oparatlonal/aupport  Impact  of  tha  diagnoatio  daflolanolas 
0  Oorractlva  •ction(s)  which  should  ba  takan  or  hava  baan  takan. 

■IT  Rfraetivanaaa 

0  Fault  isolation  tinfta. 

Tracking  of  Falaa  Alarma 
0  Type  of  alarm 

0  Praquanoy  of  alarm  ooourranoa 
0  Causa  (If  known) 

0  Potential  conaaquanoaa  of  ignoring  tha  alarm  (oraw  safaty,  mission 
rallabllNy) 

0  Oparational  oosta  of  rasponding  to  falaa  alarms  (abortad  misalons,  dagradad 
mode  oparation,  ayatam  down  tima) 

0  Support  costa  aasodatad  wim  tha  falsa  alarm 

0  Oparational  anvlronmant  whan  alarm  ooourrad. 

ATI  Iffaotlvanaaa  Paadbaok 

0  Workarounds  raquirad  to  ovarcoma  maohanical  or  alactrioal  daflolanolas  In 
tha  UUT/ATE  Intarfaoa 

0  Did  tha  ATE  systam  provida  fallura  datactlon  rasuKs  oonsistant  with  thosa  of 
Initial  fallura  datactlon  by  BIT?  * 

0  Wara  tha  ATE  taat  rasuHs  rspaatabla? 

0  Ambiguity  siza 
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0  Fault  Itolttion  tlfTw, 

IntoQintton  of  DIagnootio  Blomonta 

0  Art  dlagnoatlo  roaouroaa  provldad  oontlatont  with  tho  tralnIng/iMII  Itvala  of 
Milgnod  paraonnol? 

0  Effaot  of  ftito  altrma  and  unnaooaaary  rtmovala  on  oporatlonal  availability 
and  maintananoo  workload 

0  Shop  throughput 

0  Wrong  or  Inadaquata  taohnioai  Information 
o  Logiatia  dalay  tima 
0  BIT  rallablllty 
o  ATE  rallablllty. 


Dlagnoatlo  data  oollaotlon  and  dlagnoatlo  capability  parfonnanoa  aaaaaamant 
may  laad  to  tha  raquiramant  for  oorraotiva  action.  Corraotiva  action  may  Involve  radaaign 
of  prima  aquipmant,  taat  aquipmant,  Intarfaoa  davloaa,  maintananca  dooumantadon.  built* 
In  raat  olrouHa,  dlagnoatlo  ao^ara.  and  ATE  tait  programs.  All  ohangaa  must  ba  mada 
under  strict  configuration  control. 

Tha  designer  must  raoogniza  that  modifications  to  tha  prime  systam/aquipmant 
may  dictate  modifications  to  tha  diagnostic  capability  as  wall. 
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CHECKU8T 

of  It  thtrt  dirtet  communication  bock  and  forth  bttwatn 
tht  ptrton  who  rtporta  a  probitm  and  tht  ptrton  who 
will  bt  corrtcting  tht  probitm? 


C3f  Art  all  failurtt  btfng  onalyztd  to  tufficitnt  dtpth  to 
Idtnttiy  fotlurt  cauttt  and  perform  ntetttory 
corrtewt  oetfont? 
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1 .0  INTRODUCTION  AND  RACKQROUND 

Tht  dttign  •ngln««r  li  th«  k«y  to  tolvlng  ono  of  tho  most  ooirpltx  probloma 
facing  th§  military  aarviota  In  yaara.  Tha  problam  la  that  today's  wcupor  ayatama  hava 
baooma  ao  aophlatloatad  that  tha  oapability  to  maintain  and  rapair  tham  la  a  n^itlonal 
priority.  No  longar  can  tha  daaign  anginaar  ba  primarily  concarnad  with  tha  aquipmant 
maating  tha  operational  raquiramanta.  Raliabliity  and  maintainability  must  ba  givan  equal 
oonaldaratlon.  Conaldaratlon  can  no  longar  ba  given  only  to  varying  environmental 
oonditlona  under  which  tha  fielded  product  must  operate.  Equal  consideration  must  now 
ba  given  to  tha  conditions  under  which  repairs  will  ba  performed.  Seemly  short  and 
simple  tasks  often  baooma  vary  time  consuming  whan  accomplished  under  extrema 
tamparatura  conditions  or  In  raatrlotiva  clothing  such  as  chemical,  biologloai  or  radiological 
attire. 


Tha  aarvloaa,  burdened  with  axoaasiva  maintenance  problems,  tncraaslng 
demand  for  skilled  manpower  and  skyrocketing  costa,  hava  given  Industry  a  clear 
message.  Tha  Air  Force,  for  inatanoa,  has  Implemented  a  program  which  atatas  baaloally 
that  all  new  aquipmant  will  ba  designed  to  double  reliability  and  reduce  rapair  time  by  half. 
Reliability,  maintananca,  quality,  and  productivity  in  new  aquipmant  will  be  given  as  much 
attention  as  performance,  program  sohadula  and  coat.  Tha  affects  of  this  new  program 
can  be  seen  In  recent  development  of  a  low-altituda  navigational  system.  Performance  at 
InHIal  testing  was  with  operational  requiremanta.  However,  due  to  hlghar*than-antioipatad 
vibration  level,  reliability  raquiramanta  oould  not  ba  demonstrated.  Tha  program  wa&  not 
permitted  to  continue  to  tha  next  phase  until  reliability  reached  the  required  growth 
ourvaa.  This  created  a  delay  of  approximately  six  months,  placing  the  entire  program  in 
trouble. 


Currently,  diagnostics  design  !a  tha  major  unknown  In  tha  reliability  and 
maintainability  arena.  Tha  statistics  provided  in  this  guide's  Introduction  demonstrates  the 
magnitude  of  this  fact.  This  appendix  presents  additional  experiences  and  the  key 
learning  points  derived  from  them. 

To  Introduce  these  lessons,  a  brief  hypothetical  scenario  Is  provided  regarding 
the  start  of  a  work  day  for  an  Air  Force  technician  assigned  to  a  modem  bomber  wing. 
This  case  is  intended  to  provide  some  Insight  Into  what  diagnostics  programs  may 
someday  aoNeve. 

Arriving  at  his  duty  station,  the  technician  enters  his  code  at  a  computer 
terminal  and  Is  provided  a  work  order  for  the  first  task  of  the  day.  The  work  order 
concerne  a  malfunction  which  was  deteotsd  during  a  flight  completed  just  prior  to  his 
arrival  at  work.  A  quick  glance  at  the  work  order  reveals  which  system  failed,  what  time  K 
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oeourrtd,  and  th«  Lina  Rtplaoaabit  Unit  (LRU)  which  Is  to  ba  raplaoad  to  correct  tha 
pnablam.  After  a  quick  trip  to  a  supply  point  for  a  sarvlcaabla  LRU,  with  tool  box  and 
chaokllst  In  hand,  ha  departs  for  tha  flight  line.  Tha  defective  LRU  Is  changed  within 
minutes  after  his  arrival  at  work.  A  quick  opeiatlonal  check,  using  the  checklist  and  on¬ 
board  test  system,  confirms  that  no  other  failures  have  occurred,  and  the  system  Is 
declared  operational. 

Back  at  the  Intermediate  shop,  the  flight  line  portion  of  the  work  order  is  closed 
out.  This  Is  quiokly  done,  with  a  minimal  amount  of  Information  Input  Into  the  computer 
terminal  regarding  the  work  aooompllshed.  The  defective  LRU  Is  placed  on  Its 
corresponding  automatlo  test  equipment  (ATE).  Keys  within  the  LRU  provided 
Identification  Information  to  the  computer  contained  within  the  ATE.  Failure  conditions 
and  symptoms  recorded  on-alroraft  at  the  time  of  the  failure  are  also  transferred  to  the 
ATE  computer  via  the  computer  network.  Rapidly  the  /TE  goes  through  a  set  a  tests 
speolfloally  tailored  to  the  reported  failure  conditions  and  the  failed  single  component  Is 
Identified.  After  the  failed  component  Is  replaced,  the  LRU  Is  checked  again  with  the  ATE 
tc  verify  serviceability.  Following  serviceable  testing,  the  LRU  Is  given  s  quality  control 
Inspection  and  returned  to  the  supply  point,  where  It  once  again  becomes  a  serviceable 
asset. 


The  above  scenario  (or  parts  thereof)  has  been  a  goal  of  the  military  services 
for  many  years.  Great  strides  have  been  made  toward  achieving  this  objective,  yet  even 
total  success  In  limited  areas  does  not  lay  Immediately  at  hand. 

The  reasons  that  success  is  fleeting  are  many.  They  include  budget 
constraints,  a  relative  lack  of  Importance,  polltlcai  considerations,  time,  and  the  complexity 
of  the  task»juet  to  mention  a  few.  This  appendix  presents  a  few  glimpses  of  activity  on 
recent  programs,  results  obtained,  and  lessons  learned. 

The  Information  presented  Is  s  composite  of  experiences  derived  from  8*16 
snd  F-1 1 1  Aircraft,  as  well  as  the  Minuteman,  Peacekeeper,  and  Small  ICBM  Strategic 
Missiles.  LSA  examples  from  the  AMRAAM  and  30mm  Qun  PODS  are  alio  Included. 

2.0  E8TABU8HMINT1NTBRPRETATION  OF  REQUIREMENTS 

What  Is  specified  In  the  procurement  specification  and  the  contractual 
Statement  of  Work  Is  what  the  government  expects  to  receive.  In  the  area  uf  diagnostics, 
the  government  experience  on  past  programs  has  not  been  the  best.  DIsgnostIo  systems 
have  proven  to  be  Incomplete,  unable  to  to  test  to  the  desired  level  or  simply  do  not  as 
advertised.  The  basic  foundation  upon  which  any  success  will  be  directly  dependent  is 
the  clear  understanding  of  the  actual  requirements. 
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NMd  8tattm»ntt  and  Work  Statainanta 

All  of  fha  programs  survaysd  In  ths  praparatlon  of  this  dooumant  ssam  to  hava 
an  Itam  In  common  daaling  with  thair  diagnostic  raqulramsnts.  That  commonality  factor  Is 
that  tho  quantltatlva  diagnostic  raqulramants  imposad  ars  darivad  without  a  graat  daal  of 
thought  and  analysis.  Typically  diagnostic  raqulramsnts  sra  mora  what  has  baan  judgad 
by  somaona  to  ba  raallstic  valuas,  rathar  than  a  product  of  studlaa  parformad  to 
datarmlna  thaas  raqulramants. 

OoO*lnstruoilon‘<n000.2  and  othar  ralatad  dooumants  dasorlba  a  structurad 
acquisition  prooasa  baginning  with,  among  othar  things,  tha  davalopmant  of  a  Mission 
Araa  Analysis  and  a  Mlsslon*Naad  Statamant.  tnoludad  In  tha  MIsslon-Naad  Statament  Is 
a  discussion  of  tha  Mission  and  Thraat,  AltarnatIvs  Conoapts,  and  Taohnology 
Involvamant.  Subsaquantly,  during  tha  Conoapt  Exploration  Phasa,  studlaa  ara 
oonduotad  to  davalop  a  Systam  Conoapt  Papar  which  mora  thoroughly  daflnas  possibla 
altarnatlvaa,  and  a  salsotad  conoapt.  Many  itams  ara  takan  undar  ocnsldaration  during 
this  tims  frama  Including  raadinasa,  maintainability,  manpower  and  training. 

It  is  this  process  which  ganaraliy  drives  tha  development  of  tha  procurement 
spaolfloatlona.  These  functions  ara  primarily  tha  oonoarn  of  Qovarnmant  Program 
Manager;  however,  Inputs  ara  somatimos  raquastad  from  tha  contractor.  Failure  to 
consider  testability  whan  providing  these  Inputs  may  limit  chances  for  suooassfui 
diagnostics  later  In  tha  program.  Overall  diagnostics  and  testability,  In  general,  should  ba 
given  mora  oonoarn  at  this  aarty  stage  of  development. 

Undaratanding  Raquiramante 

Determining  tha  proper  diagnostic  specifications  nsoassary  to  meat  tha  misjlon 
need  Is  one  thing.  Describing  them  In  such  a  way  that  they  will  bo  Interpreted  property  Is 
another. 


Tha  following  Is  one  of  tha  diagnostic  raqulramsnts  Impossd  on  tha  B-1B.  Tha 
CITS  shall  provide  an  assurance  of  05  paroant  to  tha  aircrew  that  tha  systam  performance 
Is  operationally  accaptabla  or  that  tha  indicated  failure  Is  valid  during  In-flight  performance 
and  ground  readiness  tests.  Tha  CITS  ahall  provide  fault  isolation  to  an  LRU  with  a 
certainty  of  at  least  75  paroant'in  tha  ground  fault  Isolation  moda." 

Another  requirement  stated  that  "false  alarms  could  not  exceed  2  percent*. 
Both  saamingly  good  raqulramants,  but  two  problems  ensued  In  their  accomplishment. 
Firs:  and  foremost  was  tha  problem  in  tha  definition  of  tha  paroant  base.  Paroantagas  are 
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often  used  In  defining  requlremente.  But  when  so  used,  It  must  be  stated  as  a  percent  of 
what.  False  alarms,  as  a  percent  of  the  possible  alarms,  gives  one  result.  False  alarms, 
as  a  perosnt  of  the  number  of  total  alarms  indicated,  givos  another.  When  written,  one 
must  assume  that  achievement  based  on  definition  of  the  writer  would  meet  mission 
needs.  In  reality,  when  achieved  based  on  tegai  or  Implied  definition,  the  results  were  far 
from  those  required  by  the  operational  command. 

A  second  but  In  this  case  a  lessor  problem,  was  a  conflict  between  the 
requirement.  The  first  requirement  above  allows  a  5  percent  false  alarm  rate  (100  minus 
the  05  percent  accuracy).  The  second  allows  only  2  percent.  Specification  ambiguity 
leads  to  Interpretation  which  will  not  necessarily  and  with  the  desired  resuH.  The  design 
engineer  can  help  eliminate  these  problems  by  Informing  program  management  when 
speoHIcatlon  ambiguity  Is  first  encountered. 

LeglsHo  Support  Analysis  (L8A)  Proeeas 

I 

The  LSA  Is  not  a  direct  function  of  the  design  engineer,  however  the  process 
can  Influence  many  of  the  design  requirements.  MIL-STD>138F>1A  defines  basic 
objeotivea  whicn  are  achieved  when  this  standard  Is  applied. 

1.  Cause  supportablilty  requirements  to  be  an  Integral  part  of  system 
requirements  and  design. 

2.  Define  support  requirements  that  are  optimally  related  to  the  design  and 
each  other. 

3.  Define  the  required  support  necessary  during  the  operational  phase 


These  ob)eotiveo  are  accomplished  by  the  selective  application  of  scientific  and 
engineering  efforts  undertaken  during  the  acquisition  process,  as  part  of  system 
engineering,  it  Is  an  Iterative  process  of  definition,  synthesis,  trade-off,  test  and 
evaluation.  Many  oases  have  been  found  which  indicate  that  designers  who  successfully 
Incorporate  the  results  of  these  studies  early  will  have  a  maintainable  system  when 
deployed  In  the  field. 
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3.0  STRUCTURING  DBSIQN  CONCEPTS/CONSTRAINTS 
Controlling  vt  Constraining  tho  Contractor 

Today's  trsnd  In  spaolfloation  and  oontraotor  diraotlon  la  to  provide  tha 
contractors  with  ths  msKlmum  laaway  In  maating  top*laval  raquiramants.  Tha  objaotiva  Is 
to  allow  tha  contractor  to  dafina  altarnativaa.  salact  from  tha  altarnstivss  those  which  can 
bast  be  aooompllshad  and  provide  a  product  which  meats  all  of  ths  "rear  rr'iulramants. 

Existing  systems  covered  by  this  document  ware  all  developed  under  a  more 
structured  specification  approach.  The  prevloua  school  of  thought  was,  generally 
speaking,  that  tho  more  things  which  can  be  controlled  by  the  specifications,  the  more 
chance  the  end  product  will  be  as  desired.  Experience  with  that  approach  has  led  to  the 
more  open  trend.  This  Is  because  the  tighter  approach  did  not  allow  the  oontraotor  to 
make  maximum  use  of  his  many  possible  alternatives. 

The  customer  Is  encouraging  the  design  engineer  to  think  In  terms  outside  the 
realm  of  present  diagnostics  technology.  Diagnostics  technology  In  general  has  not 
developed  to  the  point  of  satisfying  the  customer's  requirements  tor  maintaining  complex 
weapon  systems.  An  excellent  example  of  the  type  diagnostice  not  desired  Is 
demonstrated  by  the  bullt<ln  fault  oapabtilty  of  a  torraln*followlng  radar.  One  of  the  line 
replaceable  units  oontsined  within  this  system  Is  the  computer.  Conveniently  located  In 
the  aircraft  noso  compartment,  this  LRU  contains  the  malfunction  Isolation  switch  and 
malfunction  Indicator  on  It's  front  panel.  The  malfunction  Indicator  has  nonvolatile  flags 
sst  during  flight  at  the  occurrence  of  a  malfunction.  These  were  designed  to  serve  as 
functional  aids  for  maintenance  personnel  troubleshooting  the  terrain*  following  radar 
system.  However,  many  of  the  malfunctions  Indicated  are  caused  by  associated 
subsystems  that  provide  stimulus  to  the  computer.  This  situation  has  caused 
unnecessary  maintenance  and  supply  cost,  plus  degraded  operational  readiness.  Xtif 
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The  Malntenanoe  Concept 

The  Logistic  Support  Analysis  tasks  of  MIL-STD-1388-1A  which  are  concerned 
with  the  development  of  malntenanoe  concepts  and  constraints  are  very  Important  for  the 
diagnostic  community.  The  design  engineer  will  benefit  greatly  by  belrig  Involved  with  the 
LSA  analyst  and  Incorporating  the  results  into  the  basic  design  at  the  earliest  possible 
time.  The  MIL-STD-1386  tasks  are  structured  to  ensure  consideration  of  existing 
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reaouroes,  compatibility  with  deployment  and  operational  requjremonta,  and  maintenance 
personnel  akill  level. 

The  tie  between  the  diagnostic  method  end  the  maintenance  concept  la 
bidirectional.  They  need  to  be  established  In  unison.  The  maintenance  concopt  Is 
'developed  based  on  expected  diagnostic  capabilities.  The  diagnostic  design  ultimately 
forces  the  real  maintenance  concept.  The  designer  who  understands  this  concept 
recognizes  the  MIL*STD‘1388  process  as  an  aid  lo  achieving  the  desired  maintenance 
concept  Is  success  oriented.  A  lesson  welt  teemed  Is  that  whan  these  tasks  are  used  for 
historical  purposes,  Instead  of  a  tool  for  the  designer,  the  desired  maintenance  concept  is 
seldom  achieved. 

Established  Air  Force  maintenance  policies  utilize  system  operation  as  the  final 
determinant  of  the  need  for  maintenance.  If  the  system  Is  functioning  within  tolerance, 
don't  fix  It.  A  unique  situation  has  developed  on  the  B-1B  aircraft.  Due  to  redundanoios 
designed  Into  the  systems,  overall  operation  appears  normal,  while  some  specific  parts 
are  not  functioning.  The  diagnostics  systems  say  the  parts  should  be  replaced.  System 
operation  Indicates  everything  Is  functioning  normally.  To  date,  partially  due  to  the  lack  of 
confidence  In  the  aircraft  diagnostics  end  partially  due  to  established  habits,  these  type 
malfunctions  are  not  being  repaired.  Csneraiiy  the  diagnostics  Is  believed  fruity  and  no 
maintenance  action  Is  taken  until  another  Item  malfunctions  rendering  the  system 
Inoperative.  This  experience  shows  that  changing  existing  practices  Is  slow.  If  it  Is 
confused  with  the  lack  of  confidence  In  the  diagnostics,  the  change  Is  even  more  difficult. 

Tne  Unit  Under  Test  (UUT)  designer,  ATE  manager,  and  automatic  test 
equipment  designer  are  all  vital  elements  In  determining  what  off*  equipment  testing  is 
required.  Once  the  option  for  automated  testing  Is  confirmed,  the  ATE  designers  must 
convince  the  UiJT  designer  to  Incorporate  "Design  To*  criteria  for  maintainability,  reliability 
and  testability.  Care  must  be  taken  to  define  the  need  for  ATE,  how  the  ATE  is  to  be 
used,  how  the  UUT  will  be  designed  for  bullt*ln  test  and  Interlacing  abilities.  ATE 
effectiveness  Is  directly  and  Immediately  dependent  upon  this  co  developmem  with  the 
unit  under  test.  The  following  support  trade-off  factors  must  be  considered  whan 
developing  the  UUT  "Do&lgn  To"  criteria: 

1 .  The  mu.ntenance  concept  and  requirements  imposed  by  the  Repair  Level 
Analysis  of  the  system 

2.  Requirements  of  the  built-in  test  for  the  UUT 

3.  The  effectiveness  of  UUT  functional  partitioning 
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4.  The  ability  to  Insert  In  th»  (JUT  test  points 

5.  Design  limits  on  reliability  and  maintainability. 

His\orloally,  probably  the  prime  reason  for  dissatisfaction  with  a  weapon 
system’s  diagnostic  capability  la  the  unnecessary  removal  of  "good”  Items  when 
conducting  corrective  maintenance.  The  designer  must  be  aware  of  the  causes  for  these 
unnecessary  removals. 

A  field  survey  team  (details  of  the  survey  are  contained  In  RADC*TR*83‘2 
"Study  of  the  Causes  of  Unnecessary  Removals  of  Avionic  Equipment")  visited  12  APB’s 
In  1970  to  determine  the  causes  of  this  problem.  When  the  survey  was  completed,  a 
study  analyzed  the  data  and  categorized  the  causes.  The  following  major  causes  of 
unnecessary  removals  (URs)  are  listed  along  with  the  percentage  of  all  URs  for  which 
they  are  responsible. 

Ineffective  BIT  •  36% 

This  problem  relates  to  builMn«test  designs  which  provide  incomplete  or 
ambiguous  Information  to  aircrew  and  grpund  crew  operators.  Such  Incomplete 
Information  is  the  reason  that  operatoni  must  Interpret"  BIT  Indications.  Thus,  there  are 
Instances  when  BIT  indloatlons  are  misinterpreted  and  an  avlonio  equipment  is 
erroneously  reported  as  malfunctioning.  Such  "malfunctions"  are  termed  false  alarms  and 
result  In  a  CND  or  UR  olassHfcatlon.  These  false  alarms  may  either  indicate  a  malfunotlon 
in  a  serviceable  equipment  when  there  is  actually  no  malfunction  In  the  system,  or  may 
not  indicate  a  fauH  when  one  existe  In  the  equipment. 

Ineffective  SuoervIslon^SuDQJrt « 26% 

This  problem  Involves  control  of  the  work  habits  of  maintenance  technicians. 
Although  a  lack  of  such  support  may  be  a  result  of  the  current  short  supply  of  middle 
management  personnel,  special  attention  of  supervision  is  often  necessary  to  maintain 
control  of  the  UR  rate. 

Lack  of  adequate  troubleshootitig.  Incorrect  use  of  teat  equipment,  improper  or 
Inadequate  documentation,  and  lack  t  historical  tracking  of  aircraft  and  LRIJs  for 
intermittent  problems  all  tend  to  point  to  L.e  lack  of  effective  direct  supervision. 
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Mintgemtnt  DIfotIvtt » 1 1% 

This  problem  rslatst  to  bypaasinp  tho  normal  standard  troubisshooting 
prooaduraa  to  obtain  quick  ra sponsa  turnaround  timas  for  priority  aortlas.  Thara  art  times 
whan  turnaround  tima  la  most  Important  and  any  supporting  action  la  JuatHlad.  Howavar, 
this  typa  of  nonstandard  action  ahould  ba  undar  ragular  survalllanos  by  auditing 
parsonnal. 

Hat,  Eflulpmt  ntfilfff 

Tast  aquipmant  diffarancas  batwaan  dtffarant  lavala  of  maintananoa  wara  notad 
by  tha  survay  taam  on  ralativaly  "naw"  aquipmant.  A  lack  of  oommonallty  in  tha 
calibration  of  tast  aquipmant  was  also  disoarrfad  by  tha  flald  survay  taam  at  ona  rapair 
faoliny.  At  ona  AFB,  cartaln  LRUs  raoalvad  from  tha  rapair  dapot  ara  rstastad  baoauaa  of 
tha  lack  of  commonality  batwaan  I'laval  tast  aquipmant  and  dapot  lavai  tast  aquipmant. 

Inaffactiva  or  Mtsslno  Tast  Eoulomant  -  9% 

This  inoludas  haavy  or  bulky  tast  aquipmant.  In  most  oasas  Inaffactiva.  haavy 
or  unwialdy  tast  aquipmant  Is  tha  sama  as  missing  tast  aquipmant  stnoa  It  Is  not  usad.  In 
this  oasa,  nonstandard  troublashooting  Is  omptoyad. 

Inadaouata  Skill  •  7% 

Inadaquata  skill  of  maintananoa  taohnioians  In  tha  usa  of  T.O.s.  tast  aquipmant 
and  troublashooting  prooaduras  ralatas  to  tha  taohnioians*  Inability  to  oomplataly  oopa 
with  tha  ralativaly  high  taohnology  of  alaotronie  aquipmant.  Thia  oausa  of  URs  Is  dua  to 
tha  taohnlolan  not  ramambaring  datalls  of  his  past  training;  ba  it  formal,  on>tha*)ob 
training,  tachnioal  raadings  or  just  familiarization  with  aquipmant  and/or  avsiiablo 
dlognoatlo  mathods. 

IPiCfitlilbllBx 

In  addition  to  tha  abova,  tha  problem  of  inacoasslbllity  cannot  ba  ovarlookad. 
An  Inaceassiblllty  problem  can  have  a  significant  impact  on  tha  unnacassary  removal  rata. 
Whan  LRUs  ara  not  readily  acoasslblo  dua  to  soma  rastrictad  location,  tha  removal  of  a 
suspect  LRU  may  require  the  removal  of  one  or  more  adjacent  LRUs.  Also,  tha  difficulty 
In  reaching  a  suspect  LRU  may  preclude  an  on*equipment  check,  and  the  suspect  LRU  Is 
removed  and  sent  to  the  l-level  shot  for  bench  check. 
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4.0  MEANINGFUL  PREDICTION  AND  ASSESSMENT  METHODOLOGY 

In*proot08  MMtiment  of  diagnostloi  aohlovomontt  hat,  In  tha  past,  baan  lait 
than  adaquata.  In  fact,  ona  of  tha  most  dafinitiva  and  oftan  rapaatad  B-1 B  lattont  it  tha 
naad  for  an  oparational  parlod  to  matura  tha  diagnottio  datign.  That  lataon  it  datcrlbad 
balow  In  paragraph  7.0.  Pradlotion  and  Mtaatmant  taohniquat  hava.  In  tha  patt,  fallad  to 
provlda  tuffidant  Information  to  unoovar  all  of  tha  Inadaquaolat  and  thortoomingt. 
Significant  amphatia  It  ourrantly  baing  plaoad  on  tattablllty  analytlt,  rallablllty,  and 
r ’^Intalnablllty  ataatamant  toola  undar  tha  umbralla  of  Computar-Aldad  Aoquititlon  and 
Loglatio  Sup^rt  (CALS).  With  that  amphatit,  ona  thould  axpaot  graat  Improvamantt  In 
aaaaaamant  taohniquat.  Tha  point  for  tha  daaign  anginaar  on  thia  aubjaot  It  that  tha 
ratuitt  of  thaaa  pradiotlont  and  ataoatmantt  mutt  bo  Inoorporatad  into  tha  dotign  to 
diagnottloa  raquiramantt  will  ba  fuHillad. 

\ 

Mathodology 

Tha  CALS  initlativa  would  inoiuda  diagnottloa  tatting  aa  an  intagrai  part  of  CAD 
dtMgn.  Tha  eonoapt  la  that  rulaa  and  taohniquaa  would  ba  aatabllahad  In  tha  CAD 
maohina.  At  a  tpaolflo  Itam  it  daalgnad,  it  la  oonatantly  ohaokad  for  taat  aooatt,  bulIMn 
taat  oapabiilty.  or  whatavar  othar  rulaa  that  hava  baan  aatabllahad. 

ThIa  oonoapt  worka  fina  for  avaluating  tha  diagnottio  oharaotarlatloa  of  a  tingla 
alfotronio  ataambly.  Evaluation  of  a  waapon  tyttam't  oantral  taat  ayatam  It  anothar 
quattlon.  For  tha  B*1B,  a  oomplata  Intagration  iab  wat  davalopad  to  tatt  tha  diagnottloa 
toftwara  In  a  functional  anvironmant.  That  prooaat  wat  utaful,  but  atlli  undar  tha  boat  of 
lab  oondltlona  toma  thingt  oould  not  ba  davalopad  to  tha  optimum  laval.  An  axoailant 
axampla  It  tha  phllotophy  for  ohaoking  tha  thrutt  of  a  Jat  angina.  SImulatad  lab 
oondltlona  aquata  mora  to  an  aircraft  baing  on  tha  ground.  Thara  thrutt  la  oomparad  to  a 
rafaranoa  tohadula  of  groaa  thrutt  varaut  turbina  blada  tamparatura  at  two  ditorata 
oparating  pointt.  Thaaa  two  pointt  ara  tha  Intarmadlata  and  maximum  powar  aattingt. 
To  davalop  an  In-flight  thruat  ohaok,  a  rafaranoa  hat  to  ba  oaloulatad  to  monitor 
parformanoa  aoroat  tha  ahtlra  powar  ranga.  Thia  rafaranoa  it  obtalnad  by  comparing  tha 
anginat  In  tynohronization  to  ona  anothar  in  flight.  Thia  rafaranoa  raquiramant,  plut 
many  praoonditlont  naoattary  for  calculating  or  examining  thrutt.  dictated  aotual  flight 
tatting  for  davalopmant  of  a  valid  ohaok. 
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PMdbaek  Stnieturt 

TImt  It  nttdtd  to  atturo  that  tha  daalgn  banafitt  form  tha  aaaaaamant 
prooaaa.  Logioally,  ona  doat  not  naad  a  whola  lot  of  axparlanoa  to  undaratand  this. 
Howavar,  it  was  provad  onoa  again  on  tha  B-1B  aircraft  that  oompraatad  aohadulaa  land 
to  allmlnata  thia  tima.  Conourrant  FuH-Soala  Davalopmant  and  Production  maant  that  tha 
funding  for  atudlaa  and  analyala  ooourrad  ao  lata  that  raaulta  oould  not  ba  Implamantad. 
Whan  thia  happana,  managamant  diraotlon  la  naadad;  howavar,  managamant  cannot  taka 
any  action  unlaaa  tha  problam  la  brought  to  thair  attantlon.  Tha  daalgn  anginaar  muat 
notify  managamant  or  tha  magnituda  of  tha  problam  will  Inoraaaa  with  tha  paaaaga  of 
tIma. 

Infermatfon  Plow 

A  oonoam  oftan  axpraaaad  by  many  daalgn  anginaara  la  tha  dalay  In  raoalvlng 
formal  produota  ganaratad  with  tha  MIL>8TD"1388  prooaaa.  Certainly  thia  dalay  can 
oraata  conoarna.  Who  wanta  to  think  tha  daalgn  la  atabla  only  to  diaoovar  major  changaa 
ara  raquirad?  Tha  driving  faotora  oftan  naoaaaltatlng  thaaa  ohangaa  ara  atudlaa 
parformad  for  maintainability  and  taatabllHy.  Tha  daalgn  anginaar  who  raallaaa  thia  and 
davalopa  a  eloaa  working  ralatlonahip  with  tha  paraonnal  performing  thaaa  atudlaa  will 
hava  fawar  aurpriaaa.  Exparlanoa  has  taught  many  timaa  that  It  la  muoh  aaalar  to 
oommunloata  and  Incorporate  ohangaa  during  tha  Initial  daalgn  effort.  Trying  to  make 
ohangaa  later  la  axpanalva,  time  oonauming  and  oftan  produoaa  laaa  than  optimum 
raaulta. 

8.0  DISfONRlVIlWS 

Formal  Daalgn  Ravlawa  provide  tha  opportunity  for  tha  contractor  to 
damonatrata  to  tha  ouatomar  tha  praaant  daalgn  and  what  future  daalgn  afforta  hope  to 
aohlava.  If  tha  contractor  can  damonatrata  that  ha  la  meeting  tha  apaolfloatlona,  tha 
ouatomar  can  aak  no  more.  It  la  tha  role  of  tha  daalgn  anginaar  to  aaaura  that  aufflolant 
daalgn  haa  bean  parformad  prior  to  Daalgn  Ravlawa,  which  can  damonatrata  with  a 
degree  of  oonfidanoa,  that  dlagnoatlo  raquiramanta  ara  being  fulfilled. 

Scheduling 

It'a  either  too  early  or  too  lata.  Picking  tha  optimum  time  for  ravlawa  la  vary 
Important.  Ravlawa  naad  to  ba  conducted  after  tha  daalgn  la  aufflolantly  defined  to  make 
tha  evaluation  but  before  It  la  too  lata  to  make  daalgn  ohangaa.  Tha  daalgn  anginaar 
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netds  to  partlolpato  in  tohadula  davalopmant  to  anturo  that  a  revlawabla  product  It 
avallabla  at  tha  sohaduled  tima. 

Tha  only  Idantiflad  laaaon  laamad  from  axparlanoa  Is  that  tha  sohaduling  for 
formal  ravlawa  Is  fyploally  datarmlnad  at  tha  baginning  of  tha  program.  Tha  ataga  of  tha 
dasign  for  tha  raviaw  la  than  whatavar  It  la  at  tha  aohadulad  tIma.  Thia  is  not  naoassarily 
bad,  baoausa  typically  tha  daaignars  Influanoa  tha  work  sohaduia  toward  having  a 
ravlawabla  product  on  tha  astabllshad  sohaduia.  Usually,  ravlaws  cannot  ba  movad  out 
without  Jeopardizing  program  sohadulas.  Daaignars  must  guard  against  committing  to  a 
sohaduia  with  goals  that  are  unraallstlo. 

Raviaw  Bmphaaia 

Massagas  ara  aomatimas  sant  to  daaignars  which  can  ba  mlaintarpratad. 
Informing  tham  whara  thay  should  plaoa  amphasla.  This  mlalntarpratatlon  is  based  on  tha 
Importanoa  an  Item  Is  given  In  tha  ravlawa.  If  tha  Qovarnmant  Program  Manager  and  his 
raviaw  team  plaoa  little  emphasis  on  diagnostlos,  designers  gat  tha  massage  that 
diagnostics  ara  *not  Important.”  This  has  often  bean  dona  unintentionally  In  tha  past  by 
quickly  passing  over  tha  subjaot  In  tha  reviews,  or  otherwise  Indicating  a  minimal  eonoam. 
Tha  dasign  engineer  muat  not  forget  tha  importanoa  of  diagnostlos,  aspaolally  In  oases 
whara  tha  Qovarnmant  raviaw  team  has  placed  little  emphasis  on  tha  subjaot. 

6.0  DBMON8TRATION8 

Damonstratlona  ara,  In  general,  another  form  of  a  formal  raviaw.  Thus,  most  of 
the  points  made  In  tha  previous  saotion  also  apply  hare. 

TImsIlnasa 

Tha  opportune  time  for  final  demonstration  of  diagnostlos  does  not  exist.  If  a 
purpose  of  the  demonstration  is  to  Identify  corraotlva  actions.  Efforts  to  sohaduia 
damonstratlona  early  enough  to  minimize  tha  Impact  of  "failure”  have.  In  tha  past,  resulted 
In  tha  simulation  of  too  many  conditions  and  rssouroas.  To  perform  a  oomplata 
diagnostlos  demonstration,  all  operational  diagnostics  tools  must  ba  In  plaoa.  This 
Inoludas  support  equipment  (If  appropriate),  training,  taohnioal  publloatlons,  and  any  other 
applicable  diagnostic  tool.  Attempts  to  simulate  or  work  around  tha  abaanoa  of  these 
operational  Hams  does  not  provide  for  a  oomplata  demonstration. 
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SimulaUKi  vt.  Oparatlonal  Comfltlona 

This  problam  oan  b«  damonatratad  by  axparlanoa  with  a  raoant  modifloatlon 
program  on  tha  P*1 11 D  Attack  Radar.  Tha  modification  was  major*<malnly  mada  to 
Improve  rallablllty  and  maintainability.  Ona  significant  portion  of  tha  modifloatlon  was  tha 
ra-work  of  tha  bullt*ln  taat  (BIT)  oapabllltiaa. 

Tha  daaign  job  saamad  to  ba  dona  vary  wall.  Daaign  Ravlaws  wara  paaaad. 
Damonatrations  of  tha  naw  BIT  parformanoa  in  tha  laboratory  axoaadad  tha  apaolfloatlona 
and  axpaotatlona.  All  looked  Ilka  a  |ob  wall  dona  and  tha  contract  was  oonaldarad 
oomplata. 


Tha  problam  was  that  on  tha  aircraft,  In  oparational  oonditiona,  tha  BIT  doaa  not 
do  ao  wall.  Tha  BIT  aarvaa  two  functions,  ona  baing  to  adviaa  tha  alroraw  If  tha  salectad 
moda  la  oparatlonal,  tha  other  aarving  as  a  diagnostics  aid  to  maintananoa  paraonnal. 
Tho  alroraw  function  performs  wall,  which  la  not  surprising,  being  part  of  tha  basic 
oparatlonal  raquiramant.  However,  tha  diagnostics  portion  of  tha  software  used  In  tha 
fault  Isolation  prooass  has  required  extensive  ra-work.  At  first  glance,  ona  Is  lad  to  bailava 
that  tha  simulated  and  oparatlonal  conditions  must  differ  greatly.  This  being  tha  case, 
how  doaa  ona  explain  that  problems  reported  during  field  operations  oan  later  ba 
demonstrated  under  laboratory  conditions?  Performing  damonatrations  with  tha  primary 
objective  of  showing  oparatlonal  raquiramants  are  being  fulfilled,  with  diagnostics  given 
secondary  conoarn,  only  delays  finding  problems  in  that  area.  An  Important  point  to 
ramambar  Is  that  diagnostics  must  ba  given  equal  oonsideration  to  oparatlonal 
raquiramants  and  tha  Demonstration  phase  is  another  chance  to  Identify  and  start 
oorraoting  diagnostio  problems. 

Providing  for  Raaouroaa 

Sohaduling/obtalning  raaouroas  for  tha  demonstration  Is  an  early  function.  This 
raquiramant  has  often  bean  overlooked  or  minimized  In  tha  past.  Design  engineers 
involved  In  tha  demonstration  prooass  should  ba  fully  aware  of  tha  demonstration 
plan/raquiramants  and  assure  that  required  assets  are  Inputted  for  Incorporation  In  top- 
level  planning  documents. 

7.0  MATURATION 

Maturation  la  a  phase  which  has  bean  Identified  as  necessary  primarily  during 
development  of  naw  aystams/tachnology  for  tha  embedded  and  external  diagnostic 
capability.  Ona  aspaolaliy  critical  aroa  for  these  systama  Is  tha  Inherent  raquiramant  for 
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totting  undtr  actual  operating  oondltlont.  Maturation  baoomaa  nacetsary  to  rtfl^d  test 
math^ault  llmitt/dlagnoatlos  logic  tmbaddad  within  the  diagnostics  softwara  prdgrams 
that  operate  these  eystema.  The  predicted  operating  oharacterlstlo  of  the  various  on¬ 
board  systems  must  be  compared  to  the  actual  operating  characterlstlos  of  these  systems 
as  they  interface  with  other  systems  under  varying  environmental  conditions. 

Early  Planning 

One  thing  learned  on  the  B-1B  is  that  the  design  engineer  must  keep 
management  informed  of  the  conslderabie  time  and  resources  necessary  for  maturation. 
The  original  B-1B  development  plan  was  to  mature  the  diagnostics  system  (CITS)  on  70 
F8D  flights.  That  would,  It  was  thought,  provide  a  mature  eystem  at  the  time  of  the  first 
deployment  of  the  B-1B  to  an  Air  Force  Main  Operating  Base.  Early  In  the  Full-Scale 
‘  Development  Phase,  It  became  evident  that  the  plan  would  not  be  sufficient.  A  new  plan 
was  developed  to  use  408  SAC  sorties  over  the  years  1985  and  1986.  The  wing  did  not 
fly  the  required  number  of  aortlea  over  that  time  period  and  the  program  was  extended 
through  November  of  1987.  Additional  aircraft  deliveries  and  an  Increase  in  eortle 
generation  rate  produced  a  total  of  1009  sorties  by  the  end  of  that  period.  With  that 
number  of  sorties,  sufficient  data  was  gathered  to  Indicate  an  acceptable  level  of 
performance.  At  this  point.  It  la  estimated  that  as  a  general  rule,  at  least  400  to  500 
sorties  will  be  required  to  mature  an  on-board  test  system  like  the  CITS.  Maturation  time 
Is  difficult  to  estimate  and  as  learned  on  the  B-1B  changes  will  have  to  be  made  as  the 
process  matures. 

Operatlonel  or  Flight  Teat  Environment 

How  does  one  plan  for  600  sorties  prior  to  production?  la  a  plan  to  fly  four  FSD 
aircraft  on  the  average  of  once  every  three  calendar  days  for  a  year  reasonable?  Is  a 
limited  production  block  appropriate  for  maturation?  These  are  queatlons  which  the 
design  engineer  muat  consider  when  advising  management  of  sohedulea  early  In  program 
planning, 


Experience  has  Identified  one  additlonci  consideration  to  be  Included  In  making 
these  decisions.  That  consideration  Is  the  impact  a  partially  working  diagnostics  system 
has  on  the  maintenance  technician.  If  technicians  lose  confidence  In  a  diagnostic  aid, 
they  will  not  use.  Further,  It  Is  hard  to  convince  them  that  the  Item  has  been  Improved  and 
that  ndw  they  can  have  confidence  in  It.  Many  maintenance  technicians  on  the  B-1 B,  F- 
1 1 1  and  other  systems  who  have  been  exposed  to  Inaccurate  diagnostic  methods  have 
never  been  convinced  to  use  an  "Improved”  version.  All  B-1  B  operating  bases  have  the 
same  current  version  of  CITS.  Field  data  shows,  however,  that  the  bases  exposed  to  the 
earliest  and  poorest  version  of  CITS  continue  to  have  the  highest  false  alarm  and  cannot 
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dupileat*  maintananoa  rataa.  Thia  is  dua  to  tha  lack  of  truat  still  oarriad  from  tha  aarly 
axparlanoa.  Thus,  it  la  Important  to  aooomptlsh  maturation  away  from  tha  majority  of 
oparatlonal  taohniolana.  If  poaalbla. 

Implamanting  Maintananea  Conoapt 

If  tha  maintananoa  oonoapt  utilizing  tha  plannad  diagnostics  Is  significantly 
diffarant  from  that  with  which  tha  astabllshad  taohnioian  Is  familiar,  apaolal  training  will 
naad  to  providad.  Tha  B*1  B  conflict  batwaan  using  CITS  or  systam  parformanca  to  rula 
that  a  failure  has  occurrad  waa  dlscussad  In  paragraph  3.0  of  this  Sf^^andix.  Trands  ara 
also  In  plaoa  today  to  laolata  to  and  raplaoa  modules  on  tha  aircraft  rather  than  tha  larga 
"boxas”  of  tha  past.  Utilizing  tha  diagnostio  Indication  produced  during  flight  without 
further  ground  vartflcatlon  Is  also  a  currant  trend.  Each  of  thaaa  "naw”  oonoapta  must  ba 
thoroughly  understood  by  tha  taohnioians.  so  that  tha  maturation  raaults  ara  conalstant 
with  tha  plannad  fielded  maintananoa  oonoapt.  Making  ohangaa  Is  never  an  easy 
process  and  tha  maintenance  technician  Is  no  exception  to  this  oonoapt. 

8.0  SUMMARY 

Dlagnostlca  Is  not  a  simple  matter  and  tha  perfect  situation  portrayed  In  tha 
Introduction  has  yet  to  ba  achieved.  Instead  of  tha  failure  being  Identified  to  one  LRU, 
often  tha  ambiguity  group  la  as  many  as  four  LRUa.  Tha  ATE  which  can  laolata  tha  failure 
to  a  single  failed  component  would  ba  tha  Ideal  solution  but,  more  likely  than  not.  It  will 
only  ba  one  or  sometimes  several  Shop  Rapiacaabla  Units  (SRUs)  or  a  particular  group  of 
SRUs.  Tha  steps  covered  hare  ara  only  soma  of  tha  vary  basic  ones  required  to  insure 
good  diagnostics.  However,  looking  at  many  different  programs,  one  finds  even  thass 
simple  steps  have  bean  omitted,  or  perhaps  accomplished,  at  a  time  too  lata  to  have  tha 
desired  results.  Tha  reasons  ara  many:  poor  communication  of  needs  or  goals,  time 
frame  rastiiotlons,  money,  and  failure  to  properly  consider  tha  Importance  of  diagnostics. 
To  ensure  diagnostics.  It  must  ba  addressed  at  ail  phases  and  be  given  equal  Importance 
to  other  performance  requirements.  If  the  system  cannot  bo  maintained.  It  can  never 
meet  its  operational  requirements. 
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CHECKU8T 


S/  Studita,  analyaaa,  and  faadback  take  time.  They  need 
to  be  aeheduled  ao  thot  their  reeulta  con  influence 
the  deaign. 

S/  Teat  equipment  deaignera  need  to  hove  an  input  regard¬ 
ing  the  detign  requirementa  of  the  unite  to  be  taated. 

SST  Proper  prioritiea  need  to  be  demonetroted  by  both 
government  and  induatry  If  diagnoatiee  it  to  be 
properly  implemented. 

Specificationa  muat  be  well  defined  and  repreaent 
exoctly  what  ia  needed. 

Real  operating  time  ia  required  for  maturation  of 
the  diagnoetic  qyetem— Iota  of  It. 
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U8T  OF  ACRONYMS 


ABI 

Avionics  But  Inttrftoo 

ADA 

Adaptivt  DIagnottIo  Authoring 

ADS 

Adaptive  DIagnottIo  Syttam 

AFLC 

Air  Forot  Logittict  Command 

ADP 

Automatic  Data  Prooatting 

AFSC 

Air  Forot  Syatamt  Command 

Al 

Artiflolal  Intalllganoa 

AIDA 

Corporation  •  Santa  Clara,  CA 

ALU 

Arlthmatio  Loglo  Unit 

AMC 

Army  Matarlal  Command 

AMRAAM 

Advanoad  Madlum  Rang#  Air>to*Alr  MIttlla 

ASIC 

Apptloatlon  Spaolfic  Intagratad  Circuit 

ASTEP 

Advanoad  Syttam  TattabllHy  Analytit  Program 

ATE 

Automatic  Tatt  Equipmant 

ATF 

Advanoad  Taotloal  Rghtar 

ATQ 

Automatio  Tatt  Qanarator 

ATLAS 

Abbravlatad  Tatt  Languaga  for  All  Syatamt 

ATPQ 

Automatio  Tatt  Pattern  Qanarator 

BCPE 

BIphata  Corralator  Prooatting  Elamant 

BDL 

Behavioral  Datign  Languaga 

BILBO 

Built-In  Loglo  Block  Obtarvatlon 

BIST 

Built-In  SaH  Teat 

BIT 

BulK-ln  Tatt 

BITE 

BulH-ln  Tatt  Equipmant 

BLM 

Behavioral  Loglo  Modal 

BMM 

Bulk  Memory  Module 

C/ATLAS 

Common  Abbravlatad  Teat  Languaga  for  All  Syatamt 

CAD 

Computar-Aldad  Datign 

CADAT 

Computer-Aided  Datign  S  Tatt 

CADAT  6 

Computar-Aldad  Design  a  Tatt,  Version  6 

CADBIT 

Computar-Aldad  Datign  for  BulK-ln  Tatt 

CAE 

Computar-Aldad  Engineering 

CALS 

Computar-Aldad  Acquisition  a  Logittlot  Support 

CAMELOT 

Computer-Aided  Maatura  for  Logittio  Tattablllty 

CASS 

Consolidated  Automated  Support  Syttam 

CATS 

Computer-Aided  Tatt  Syttam 

CDDB 

Common  DIagnottIo  Data  Bata 

CDL 

ClrouH  Datorlptlon  Languaga 

CDR 

Crldoal  Datign  Review 
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CDRL 

Contract  Data  Raquiromtnta  Llat 

CEP 

Count  Enable  Parallel 

CEPS 

errs  Expert  Parameter  S^tem 

CET 

Count  Enable  Trickle 

CPE 

Contractor  Pumiahed  Equipment 

Cl 

Configuration  Itema 

CITS 

Central  Integrated  Teat  Syatem 

CLK 

ClooK 

CLR 

Clear 

CMC 

errs  Maintenance  Code 

CMOS 

Complementary  Metal  Oxide  Semiconductor 

CML 

Current  Mode  Loglo 

CMOS 

Complimentary  Metal  Oxide  Silicon 

CND 

Cannot  Duplicate 

CNO 

Chief  of  Naval  Operatlona 

COPTR 

Controllablllty*Odaervabillty*Predlotablllty  TeatabllKy  Report 

CPCI 

Computer  Program  Configuration  Item 

CRC 

Cyclic  Redundancy  Check 

CSC 

Computer  Syatem  Component 

CSCI 

Computer  Softarare  Conf^juratlon  Item 

CSDM 

Computer  Syatem  DIagnoetIo  Manual 

CSI 

CADAT  Syatema  Interface 

CSOM 

Computer  Software  Operitor*a  Manual 

CTE 

Commercial  Teat  Equipment 

CTF 

Controllability  Tranafer  Factor 

CY 

Controllability 

D-Ltvtl 

Depot  Level 

DAISY 

Manufacturer  Name  •  Mountain  View,  CA 

DATPQ 

Digital  Automatic  Teat  Program  Generator 

DBDD 

Data  Baae  Dealgn  Document 

DCP 

Deolalon  Coordinating  Paper 

Dtm/Val 

Demonatratlon  and  Validation  (Phaae) 

DPT 

Dealgn  For  Teatablllty 

DIA 

Defenae  Intelligence  Agency 

DID 

Data  Item  Deaorlptlon 

DIP 

Dual  In-line  Package 

DMUX 

Demultiplexer 

DoD 

Department  of  Defenae 

DoD*D 

DoD  Directive 

DoD-INST 

DoD  Inatruotlon 

DNE 

Data  Network  Element 

DT&E 

Development  Teat  and  Evaluation 
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DTA 

Daisy  TaatabllKy  Analyzar 

EARS 

Enginaaring  Aoeass  Routlna  Sat 

ECL 

Emittar  Collaotor  Loglo 

ECC 

Error  Corraotirtg  Coda 

ECL 

Emlttar«Couplad  Logic 

ECP 

Enginaaring  Changa  Proposal 

EDIP 

Elaotronlo  Dasign  Intarohanga  Format 

EIA 

Elaotronlos  Industry  Association 

E8U 

Elamant  Supervisor  Unit 

ETE 

Elaotronlo  Tast  Equipment 

FA 

Falsa  Alarm 

FA 

Feedback  Analysis 

FCA 

Functional  Configuration  Audit 

FD 

Fault  Dataotlon 

FEFI 

Fraction  of  Erroneous  Fault  Isolation  Results 

FFD 

Fraction  of  Faults  Oataotad 

FFI 

Fraction  of  Faults  Isolated 

FI 

FauM  Isolation 

FIG 

FauK  Isolation  Group 

FIPAO 

Failure  Indantifloation,  Prevention  and  Dataotlon 

FIS 

Fault  Isolation  System 

FLEX 

Name  (Navy  Su^rt  Cost  Modal) 

FMEA 

Failure  Modes  and  Effaota  Analysis 

FMECA 

Failure  Modes,  Effects  and  Criticality  Analysis 

FOM 

Rgura  of  Merit 

FOT&E 

Follow«On  Operational  Tast  ft  Evaluation 

FPPE 

Floating  Point  Processing  Elamant 

FRACAS 

Failure  Reporting,  Analysis  and  Corractiva  Action 

FSD 

FulLSoala  Davalopmant 

FSM 

Firmware  Support  Manual 

FYDP 

Five  Year  Defense  Plan 

QFE 

Government  Furnished  Equipment 

QIMADS 

Ganartc  Integrated  Maintenance  Dlagnostios 

QM 

Global  Memory 

QPETE 

General  Purpose  Electronic  Test  Equipment 

QSE 

Ground  Support  Equipment 

HDL 

HITAP 

HITS 


Hardwart  Daaorlpllon  Languaga 
Hl-Taatablllty  Analyalt  Program 
Hlararohloal  Intagratad  Tost  Simulator 
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I 


i 


HSDB 

High«Spttd  Data  But 

HW 

Hardwart 

HWCI 

Hardwart  Configuration  Itam 

I’LiVtl 

Intarmadlata  Laval 

I/O 

input/Output 

1C 

Intagratad  Circuit 

ICE 

Intagratad  Conoaptual  Environmant 

ICNIA 

Intagratad  Communloatlona.  Navigation  & 
Idantmoatlon 

ID 

Intarfaoa  Davloa 

ID 

Intagratad  DIagnoatiea 

IDD 

Intarfaoa  Oaaign  Dooumant 

IDS8 

Intagratad  Dlagnoatloa  Bupport  8yatam 

IFTh 

Intarmadlata  Forward  Tatt  Equipmant 

IQES 

initial  Graphloa  Exohanga  Bpacifloatlon 

IL8 

Intagratad  Loglatio  Bupport 

IL8P 

intagratad  Loglatio  Bupport  Plan 

IMI8 

intagratad  Maintananoa  information  Byatam 

I/O 

Input/Output 

lOT&E 

Initial  Oparatlonal  Taat  A  Evaluation 

IP8 

Intagratad  Program  Bummary 

IR8T 

Infrarad  Baaroh  and  Track 

I8P8 

Inatruotlon  Bat  Proeaaaor  Bpaolfloation 

ITC 

Intamatlonal  Taat  Confaranoa 

IIP 

Intagratad  Taat  Plan 

JTAQ 

Joint  Tatt  Action  Group 

KQM 

Kay  Qanarator  Modula 

LANA 

Looal  Araa  Natwork  Aooaiaration 

LCC 

Ufa  Cyola  Coat 

LCCATM 
LCC  Family 

Lifa  Cyola  Coat  Analyala 

of  Modi  It 

LIfa  Cyola  Coat  Family  of  Modala 

LF8R 

LInaar  Faadbaok  Bhift  Ragiatar 

LCCC 

Laadlaaa  Chip  Carrtar 

LDCC 

Laadad  Chip  Carriar 

LED 

Light  Emitting  DIoda 

LF8R 

LInaar  Faadbaok  Bhift  Ragiatar 

LOQMOD 

Logic  Modeling 

LRM 

Lina  Raplaoaabla  Modula 
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LRU 

LSA 

LSAP 

LSC 

LSI 

LSL 

LSSD 

MASA 

MATE 

McLDL 

MCTBF 

MD 

MD 

MDT 

MIDAS 

MIL-STD 

MIMOLA 

MIPS 

MISR 

MMIC 

MMS 

MMST 

MNS 

MSI 

MTBF 

MTBUM 

MTE 

MTTI 

MTTR 

MUX 

NDI 

NLFSR 

NMOS 

NSIA 

NSM 

NVBMM 

0-L«v«l 

OJT 

OSC 

OT&E 


Line  Replaceable  Unit 
Logistic  Support  Analysis 
Logistic  Support  Analysis  Plan 
Logistic  Support  Cost 
Large  Scale  Integration 
Large  Scale  Linear 
Level  Sensitive  Scan  Design 

Modular  Avionics  System  ArchKecture 
Modular  Automatic  Test  Equipment 
(Microelectronics  Center)  Logic  Description  Language 
Mean  Calendar  Time  Between  Failures 
Maintainability  Demonstration 
Multiplexed  Data 
^  Mean  Down  Time 

*  Modular  Integrated  Design  Automation  System 
Military  Standard 

Machine  Independent  Microprocessing  Language 

Million  Instnjctions  Per  Second 

Multiple  Input  Signature  Register 

Monolithic  Microwave  integrated  Circuit 

Mission  Management  System 

MIMOLA  Module  for  Self  Test 

Mission  Need  Statement 

Medium-Scale  Integration 

Mean  Time  Between  Failures 

Mean  Time  Between  Unscheduled  Maintenance 

Manual  Test  Equipment 

Mean  Time  to  Isolate 

Mean  Time  To  Repair 

Multiplexer 

Non-Developmental  Items 
Non-Linear  Feedback  Shift  Register 
N-Channel  Metal  Oxide  Semi-Conductor 
National  Security  Industrial  Association 
Network  Switch  Module 
Non-Volatile  Bulk  Memory  Module 

Organizational  Level 
On-the-Job  Training 
Oscillator 

Operational  Test  &  Evaluation 
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OTF  Observability  Transfer  Factor 

OUSD(A)  Office  of  the  Under  Secretary  of  Defense 
(Acquisition) 

OY  Observability 

P®l  Preplanned  Product  Improvement 

PAT&E  Production  Acceptance  Test  &  Evaluation 

PGA  Physical  Configuration  Audit 

PCB  Printed  Circuit  Board 

PDR  Preliminary  Design  Review 

PQA  Pin  Qrld  Array 

PIA  Programmable  Interface  Assembly 

PLA  Programmable  Logic  Array 

PLCC/PCC  Plastic  Leadless  Chip  Carrier,  Plastic  Chip  Carrier 

PMRT  Program  Management  Responsibility  Transfer 

PPBS  Planning,  Programming  and  Budgeting  System 

PROFILE  Name 

PROO/DEP  Production/Deployment  (Phase) 

PRR  Production  Readiness  Review 

RADC  Rome  Air  Development  Center 

RADSS  Random  Access  Dynamic  Set  Scan 

RAM  Random  Access  Memory 

RDGT  Reliability  Development/Growth  Test 

RF  Radio  Frequency 

RFP  Request  for  Proposal 

RISE  Readiness  Improvement  Through  System  Engineering 

ROC  Required  Operational  Capability 

ROM  Read  Only  Memory 

RTL  Register  Transfer  Language 

RTOK  Retest  OK 


SAE  Society  of  Automotive  Engineers 

SCOAP  Sandia  Controllablllty/Observablllty  Analysis 

SCP  System  Coordinating  Paper 

SDDD  Software  Detail  Design  Document 

SDI  Scan  Data  In 

SDLC  Sychronous  Data  Link  Control 

SDO  Shift  Dato  Out 

SDR  System  Design  Review 

SDS  Schematic  Design  System 

SEMP  System  Engineering  Management  Plan 

SERD  Support  Equipment  Recommendation  Data 
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SHARP  Standard  Hardwara  Acquisition  Requirement  Process 

SI  Sensor  Interlace 

SILVER  LISCO  Corporation  -  Menlo  Park,  CA 

SIT  System  Integrated  Test 

SMD  Surface  Mounted  Device 

SMS  System  Management  System 

SO  Small  Outline 

SON  Statement  of  Need 

SOW  Statement  of  Work 

SPiCE/PSPICEProgram  Name 

SPM  Software  Programmer's  Manual 

SRA  Shop  Replaceable  Assembly 

SRR  System  Requirements  Review 

SRU  Shop  Replaceable  Unit 

SSI  Small'Scale  Integration 

STATQRADE  Name  <  Statistical  Fault  Analysis  Gateway  Design 

STAMP  System  Testability  Analysis  Maintenance  Program 

STD  Software  Test  Descriptions 

STLDD  Software  Top-Level  Design  Document 

SUM  Software  User's  Manual 

SW  Software 


T/D  Testablllty/Dlagnostlos 

T&E  Test  &  Evaluation 

T  Testability 

TAB  T ape  Automated  Bonding 

TAH  T establlity  Analysis  Handbook 

TBD  To  Be  Determined 

TCQ  Timing  and  Control  Generator 

TEMS  Turbine  Engine  Monitoring  System 

TEMP  Test  &  Evaluation  Master  Plan 


TE8TGRADE  Name -Test  Vector  Grading 

TFOM  Testability  Figure  of  Merit 

THESEUS  Name 

Tl  Technical  Information 

Tl  AT  A  T  echnloal  Information  &  Training  Authoring 

TISSS  Tester  Independent  Support  Software  System 

TM  Test  and  Maintenance 

TO  Technical  Orders 

TP  Test  Point 

TPI  Test  Program  Instruction 

TPS  Test  Program  Set 

TRD  Test  Requirements  Document 
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TRITAC 

TRR 

TTL 

TY 

UMDP 

UPE 

URR 

UUT 

VHDL 

VHSIC 

VLSI 

VMS 

VPE 

WBS 

WRA 

WSTA 

XOR 

ZIP 

ZYCAD 


TrI'Servlott  Tactical  Comm.  Program 
(Joint  Services  C&C) 

Test  Readiness  Review 
Transistor>Translstor  Logic 
Testability 

Univeral  Mask  Data  Preparation 
Universal  Pin  Electronics 
Ultia-Reliable  Radar 
Unit  Under  Test 

VHSIC  Hardware  Descriptive  Language 
Very  High  Speed  Integrated  Circuit 
Very  Large  Scale  Integration 
Vehicle  Management  System 
Vector  Processing  Element 

Work  Breakdown  Structure 
Weapon  Replaceable  Assembly 
Weapon  System  Testability  Analyzer 

Exeluslve-or  (gate) 

Zero  Insertion  Force 
Company  -  St.  Paul,  MN 
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1.0  OVERVIEW 


This  appsndix  providas  Information  concarning  many  types  of  tools  that 
are  useful  In  performing  a  multitude  of  tasks  required  to  Include 
testabillty/dlagnostle  capabilities  Into  functional  designs  throughout  each  and  every 
phase  of  the  acquisition  process. 

Many  types  of  tasks  require  many  types  of  tools.  Some  tools  provide  a 
framework  so  that  other  tools  may  operate.  We  have  called  this  type,  "Tools  for 
Tools."  There  are  two  "tools"  of  this  type  included  In  this  document. 

There  are  guidance  type  tools,  such  as  military  standards.  There  are 
parametric  models  whioh  are  tools  that  are  algorithmic  and  oalculatlve  In  nature. 
One  puts  various  parameters  Into  a  parametric  model  and  obtains  certain 
parameters  of  Interest  from  It.  Models  of  Interest  of  these  types  are  Availability, 
Life  Cycle  Cost  (LCC)  models.  Level  of  Repair  (LOR),  and  Logistio  Support 
Analysis  Records  (LSAR). 

Mention  must  be  made  to  the  software  design  systems  that  perform  on 
engineering  workstations  as  well  as  to  the  software  utilities  that  compose  these 
systems.  Therefore,  both  typee  were  Included  Into  this  document  and  may  appear 
next  to  one  another  when  they  are  listed. 

There  are  a  variety  of  types  of  software  utilities.  There  are  digital 
simulators,  analog  simulators,  and  simulators  with  capabilities  to  simulate  both 
digital  and  analog,  which  we  call  mixed  mode. 

There  are  dependency  models  that  serve  in  defining  and  assessing 
testabillty/dlagnostle  capabilities,  some  of  which  come  In  the  form  of  a  software 
utility.  Some  expert  systems,  another  type  of  tool,  use  dependency  modeling 
within  their  framework.  Expert  systems,  a  branch  of  Artificial  Intelligence  (Al),  are 
finding  applications  In  defining  and  assessing  the  testabillty/dlagnostle  capability 
arena  and  a  few  of  them  are  Included  In  this  document. 

There  are  software  utilities  available  that  provide  and  display  Information 
and  others  that  process  Information.  Still  others  provide  test  engineering 
assistance  such  as  calculating  controllability  and  observability  figures. 

Last,  but  not  least.  Is  the  checklist,  useful  both  in  establishing  goals 
and/or  requirements  and  assuring  that  these  requirements  have  been  met. 

A  fact  sheet,  for  characterizing  in  a  normalized  manner  each  of  the 
software  tools  sunreyed.  Is  provided  In  Table  1. 
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Fact  Sheet  Utilized  to  Characterize  Each 
Software  Tool  Surveyed 


NAME:  The  product's  acronym  followed  by  the  full  name. 

YEAR:  The  year  the  product  waa  first  Introduced  and/or  the  year  of  the  present 
version. 

FUNCTION;  A  brief  description  or  listing  of  the  functions,  propose,  or  capabilities  of 
the  tool. 

CAPABILITY:  The  maximum  or  typical  size  of  the  circuit  or  system  the  tool  Is 
performed  on. 

CPU  TIME:  A  statement  to  provide  an  idea  of  how  much  CPU  time  will  be 
consumed  when  processing  a  circuit  or  system  of  the  above  capacity.  Any  other 
fact  relating  to  process  speed  can  also  be  stated  here. 

APPLICATION:  VLSI  PCS  SUBSYS  SYSTEM 

The  level  or  levels  of  Integration  for  which  this  tool  can  provide  any  assistance  Is 
underlined.  Most  of  these  fact  sheets  have  been  reviewed  and  corrected  by  the 
developer.  Developers  tend  to  be  more  optimistic  on  how  many  levels  of 
Integration  their  tool  will  apply, 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  FSD  PRDCTN  DPLYMNT 

The  phase  or  phases  during  which  this  tool  Is  useful  Is  underlined.  See  above 
note. 

PUBLIC  DOMAIN?  Y/N 

A  ”N*  means  the  public  cannot  obtain  the  tool.  A  few  tools  have  been  Included  with 
"N"  underscored  for  academic  purposes.  Whenever  a  "Y*  has  been  underscored, 
there  follows  either  "(QFE)",  "(UNIV)",  or  "(PRTY)".  QFE  stands  for  Government 
Furnished  Equipment,  UNIV  stands  for  "university*,  and  PRTY  stands  for  "priority". 
QFE  software  Is  distributed  by  the  U.S.  Government  at  a  minimal  price.  UNIV 
software  Is  distributed  by  the  university  responsible  for  Its  development  at  a 
minimal  price.  PRTY  software  la  published  to  make  a  profit  for  the  company  that 
developed  It.  Although  QFE  or  UNIV  software  does  have  a  minimal  price  attached, 
It  Is  considered  to  be  "FREE"  and  PRTY  software  Is  considered  "FOR  SALE". 
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SPICE  (not  PSPICE)  Is  an  example  of  a  university  developed  tool  that  Is  available 
at  a  minimal  price.  TOES  Is  an  example  of  a  university  developed  tool  that  is  not 
available.  FACE,  VICTOR,  and  PROTEST  are  three  university  developed  tools 
wherein  the  Information  as  to  their  public  access  Is  not  available  at  this  time.  The 
availability  of  ITTAP,  developed  by  ITT-LSI  Technology  Center,  Is  also  unknown  at 
this  time. 

DESIGN  ENV:  Stated  here  are  what  computer  platfomis  the  tool  will  run  on,  what 
design  system  the  tool  Is  a  part  of,  and/or  what  language  the  program  Is  written  In. 

CIRCUIT  DESCRIPTION:  All  tools  of  the  type  Included  In  this  section  require  that 
the  circuit  or  system  first  be  described  either  In  a  particular  HDL,  a  netlist,  a 
functional  block  diagram,  etc.  A  statement  as  to  how  It  Is  described  Is  provided 
here, 

USE  PREREQUISITE:  Listed  here  are  requirements  that  must  be  met  prior  to 
using  the  tool  other  than  describing  the  circuit.  Here  Is  also  where  the  Input 
parameters  would  be  listed. 

DEVELOPER:  The  name  of  the  company  or  Individual  responsible  for  developing 
the  tool, 

COMMENTS:  Statements  or  facts  not  yet  mentioned  that  would  be  Important  to 
someone  who  may  want  to  use  the  tool.  What  is  most  unique  about  the  product  Is 
Included  here. 

REFERENCES:  Sources  of  more  Information  and/or  where  to  obtain  the  tool  Is 
listed. 
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All  Of  the  tools  of  all  of  the  tool  types  mentioned  above  have  been 
categorized  by  function  (I.e.,  Requirement,  Design,  Assessment  and  Maturation). 
These  categories  are  listed  horizontally  in  Table  2  and  the  various  tool  types  are 
listed  vertically.  The  tools  themselves  are  listed  in  this  matrix.  To  find  when  a  tool 
is  used  or  for  what  task,  look  up  to  find  Its  column  heading.  To  find  what  type  a 
tool  is,  look  to  the  left  to  find  Its  row  heading. 

In  the  chart,  you  see  arrows  to  the  left  and  to  the  right  of  most  of  the 
tools.  This  signifies  that  the  tool,  or  group  of  tools,  is  useful  In  performing  more 
categories  of  tasks  than  the  ones  delegated  to  it  in  this  document.  Positioning 
these  tools  on  the  chart  was  difficult  and  It  may,  unintentionally,  generate  some 
disagreement.  Bear  In  mind  that  the  Intent  of  the  chart  Is  simply  to  provide  a 
broad  overview  of  the  tools  to  help  distinguish  the  forest  from  the  trees. 

Often  there  are  many  tools  of  the  same  type  that  are  used  for  the  same 
tasks  and  It  would  have  been  Impossible  to  fit  them  all  In  the  proper  location  on  the 
chart.  For  this  reason,  numbers  have  been  assigned  to  the  tools  according  to  how 
they  have  been  categorized  In  this  document.  For  example,  2.1.1  would  be  the 
first  tool  described  In  the  first  subheading,  "Establishing  Requirements,"  for  Section 
2,  "Requirements,"  The  numbers  3.3.2.3  refer  to  the  third  tool  listed  in  the  second 
subheading,  "ATPQ's,"  which  Is  part  of  the  third  subheading,  "Diagnostic 
Authoring,"  which  Is  part  of  Section  3,  "Design  Implementation." 
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2.0  REQUIREMENT  TOOLS 

This  section  lists  models  and  standard  procedures,  as  well  as  software 
tools  that  are  either  available  or  under  development,  to  aid  In  eatabllehing 
optimized  diagnostic  requirements  that  are  properly  allocated  to  the  various  repair 
levels  and  depict  minimum  risk  to  both  mission  success  and  life  cycle  costs. 

These  requirement  tools  have  been  categorized  with  the  following  four 
subheadings: 

0  Establishing  requirements 

0  Allocation 

0  Optimization 

0  Risk. 

The  entries  will  be  presented  In  the  above  order. 

A  major  Government  Program  established  to  assure  proper  technological 
integration  of  these  tools  is  knows  as,  "Computer  Aided  Acquisition  and  Logistic 
Support  (CALS)."  A/LICE  Is  a  software  program  that  has  been  developed  to 
provide  a  framework  for  the  Implementation  of  the  CALS  philosophy  and  will  be 
included  first  because  of  Its  nature.  It  is  a  tool  for  tools.  Another  tool  for  tools, 
"TISSS."  Is  briefly  described  In  Section  3.0,  "Design  Implementation  Tools,"  under 
the  subheading,  "Design  Rules  and  Practices." 

The  criteria  for  a  tool  being  listed  in  this  section  Is  established  by 
answering  the  following  queetlon: 

"According  to  engineering  judgment,  does  this  tool  markedly  aid  In 
the  task  of  establishing  optimized  requirements  of  an  effective 
diagnostic  system?" 

There  are  no  claims  made  that  this  Is  an  all  Inclusive  list.  There  are 
perhaps  dozens  of  tools  that  are  not  Included. 
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2.0.1  A/LICE 

NAME;  A/UCB;  ADA/LATTICE  INTEGRATED  CONCEPTUAL  ENVIRONMENT 
YEAR:  1 985  (first  operational  version) 

FUNCTION;  The  CALS  philosophy  Is  to  pool  the  knowledge  of  all  the  departmental 
experts  so  that  planners  of  a  new  weapon  system  get  as  much  of  the  big  picture  as 
possible  and.  thereby,  greatly  enhance  system  efficiency  and  the  probability  of 
success.  The  CALS  knowledge  base  requires  "super"  representation  schema  due 
to  the  fact  that  It  must  contain  diverse  specialties  and  often  competing  "liltles," 
Including,  Reliability,  Maintainability,  Availability,  ILS,  Support,  Design/Bulld, 
Planning  and  Technical  Documentation,  and  others.  This  super  representation 
schema  is  called  an  Integrated  Conceptual  Environment  (ICE). 

The  Immediate  problem  of  Implementing  such  a  philosophy  Is  trying  to  standardize 
upon  the  knowledge  representing  formats,  knowledge  that  must  somehow  be 
linked  to  text  and  graphics  and  also  to  the  various  emerging  expert  systems. 
A/LICE  is  an  Ada  coded  program  with  knowledge  lattice  extension  operators  to 
form  an  outline  for  such  an  ICE  and  to  provide  a  method  of  machine  hosting  ICE 
morphological  operatora  In  Ada.  A/LICE  thus  presents  a  solution  to  prooeseing  the 
massive  and  diverse  knowledge  requirements  of  the  CALS  program.  A/LICE  has 
the  following  features: 

-  A/LICE  can  Interface  with  diverse  expert  systems  regardlese  of 
knowledge  format,  the  language,  or  structures  involved. 

-  At  the  meta-level,  A/LICE  sees  knowledge  objects  In  lattice  arrays 
which  can  be  processed  using  standard  math  array  processors. 

-  The  A/LICE  high-level  Instruction  set  will  Interface  with  the  emerging 
eleotro-optloal  analog  computers  that  will  use  direct  capture  "Image 
as  knowledge"  processing  techniques. 

CAPACITY:  N/A 

CPU  TIME:  N/A 

APPLICATION:  VLSI  PCB  SUBSY3  SYSTEM  SYSTEM  OF 

SYSTEMS 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?:  Y/N 
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DESIGN  ENV:  Personal  computers  using  standard  math  array  processors. 

INFORMATION  BUNDLING  TECHNIQUE:  The  highest  level  operator  set  are  the 
"machine  Instructions"  anticipated  In  the  advanced  analog  optical  computers  being 
developed  by  DOD.  In  practice,  Ada  derived  hardware  description  languages  (like 
VHDL)  or  Lisp  extensions  (auch  as  EDIF)  are  simuitaneously  accommodated. 

A/LICE  conforms  to  the  TISSS  data  typing  protocol. 

USE  PREREQUISITE:  Generic  "CALS"  Input  is  anticipated. 

DEVELOPER:  Sirius,  Incorporated  (now  a  division  of  Science  Applications 
International  Corp.). 

COMMENTS:  Knowledge  of  any  kind  can  be  fused  bv  simple  procedures  If  the 
source  calculus  Is  derived  from  the  universal  structure  employed.  Image  data, 
graphic  modeling  Information,  engineering  data,  and  performance  data  can  all  be 
Integrated,  or  fused,  onto  a  common  knowledge  data  stmcture. 

It  Is  good  to  note  some  of  the  virtues  of  Ada.  Ada  Is  portable,  maintainable, 
reliable,  modular,  and  easily  upgradable. 

REFERENCES: 

1.  H.  T.  Goranson,  "An  Approach  to  Knowledge  Structuring  For 
Advanced  Phases  of  the  Technical  and  Management  Information 
Syatem,"  1st  International  Conference  on  Ada  In  the  Space  Station, 

June  1986. 

2.  H.  T.  Goranson,  "CALS  Knowledge  Bases  For  Assurance 
Technologies,*  RAM  Symposium  Jan.  1987. 

3.  H.  T.  Goranson.  "Research  and  Development  Strategy  For  Advanced 
CALS,"  Internal  Document,  Defense  Advanced  Research  Projects 
Agency,  1988. 

4.  Sirius  Incorporated 
Attn:  H.T.  Goranson 
1978  Munden  Point 
Virginia  Beach,  VA  23457 
(804)  483-9110 
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2.1  Ettabllthlng  RM|ulr«imnta 

Th«  r«qulram«nt  tools  of  this  section  have  been  categorized  with  the 
following  subheading; 

-  Establishing  Requlraments 

and  have  been  categorized  as  follows: 

Logistic  Support  Analysis  (MIL-STD>1388-1  A) 

A)  Readiness  or  Availability  Models 

B)  Life  Cycle  Cost  Models 

a)  Cost  Models 

b)  Level  of  Repair  Analysis  Models 
o)  LSAR  Data  Base  Generation 

LOQISnCa  SUPPORT  ANALYSIS  (LSA) 

DIAGNOSTIC  ACTIVITY 

The  LSA  process  Identifies  and  defines  system  ;Jiagnostlc  requirements 
and  assesses  diagnostic  capabilities. 

An  LSA  activity  Is  the  selective  application  of  scientific  and  engineering 
efforts  undertaken  during  the  acquisition  process,  os  part  of  the  system 
engineering  and  design  process,  to  assist  In  complying  with  supportablllty  and 
other  Integrated  Logistics  Support  (ILS)  objectives.  LSA  Is  a  regulatory 
requirement  and  Is  required  in  all  material  acquisition  programs  without  exception. 

The  LSA  process,  In  accordance  with  MIL<STO>  1388-1  A,  consists  cf  the 
following  series  of  tasks  that  are  tailored  to  the  partloulor  system  by  the  Statement 
of  Work  (SOW): 

100  Series: 

Program  Planning  &  Control  •  The  LSA  Plan  documents  the  LSA 
management  structure,  I.e.,  what  LSA  tasks  are  to  accomplished, 
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wh«n  taoh  task  will  ba  oomplatad,  who  will  parform  tham,  and  how 
tha  tasks  ara  Intagratad,  and  how  rasults  ara  usad. 

200  Sarias: 

•  Mission  &  Support  Systams  Dafinitlon  -  Establish  supportablllty 
objactivas  and  supportability^ralatad  dasign  goals,  thrasholds,  and 
constraints  through  comparison  with  axisting  systams  and  analysas 
of  supportablllty,  cost,  and  raadinass  drivars.  This  task  Is 
pradomlnantly  dona  manually  and  takas  many  months  to  complata. 

300  Saiias: 

•  Praparatlon  and  Evaluation  of  Altarnativas  •  Optimiza  tha  support 
systam  for  tha  naw  Itam  and  davalop  a  systam  which  aohlavas  tha 
bast  balanoa  batwaan  cost,  sohadula,  parformanoa,  and 
supportablllty. 

400  Sarias; 

•  Datarmlnatlon  of  Logistic  Support  Rasouroa  Raquiramants  •  Idanttfy 
tools,  tast  aquipmant,  sparas,  parsonnal  skills,  ate.  Thasa  tasks  ara 
spraadshaat  Intansiva. 

500  Saiias; 

•  Supportablllty  Assassmant  •  Supportablllty  tast,  avaluatlon,  and 
vaiifloation. 

Tha  LSA  Racord  (LSAR),  which  Is  praparad  In  aeoordanoa  with  MIL* 
STD* 1388-2 A,  documanta  LSA  rasults  and.  In  conjunction  with  tha  Joint  Sarvloa 
LSAR  Data  Systams,  providas  spadflo  output  raports. 

A  contractor  davalops  and  submits  LSA/LSAR  data  basad  on  tailoring  of 
LSA/LSAR  In  Contract  Data  Raquiramants  Lists  (CDRL),  Data  Itam  Dascrlptlons 
(DID),  and  ILS  Statamants  of  Work  (SOW).  LSA  data  and  an  LSA  Plan  (LSAP)  ara 
submittad  pursuant  to  MIL-STD-1388-1A  and  MIL-STD-1388-2A.  A  copy  of  tha 
LSAP  Is  also  provided  to  a  raadinass  support  rasponsibla  agency  that  either 
providas  tha  contractor  with  tha  "Joint  Service  LSAR  ADP  Systam"  as  QFP  or 
providas  validation  for  tha  contractor's  LSAR  Data  System  via  a  "Joint  Service 
Team."  Tha  contractor  than  davalops  LSA/LSAR  dots  submissions  In  support  of 
tha  following  program  alamants: 

-  Systam/Equipmant  Dasign  Program 

•  Systam/Equipmant  Reliability  Program 
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•  System/Equlpment  Maintainability  Program 

•  Human  Enginaaring  Program 

-  Standardization  Program 

-  Parti  Control  Program 

•  Systam  Safaty  Program 

•  Packaging,  Handling.  Storaga,  and  Transportability  Program 

-  Initial  Provisioning  Program 

•  Systam/Equipmant  Tastabllity  Program 

•  Survivability  Program 

-  Taohnioal  Publications  Program 

•  FaellHIas  Program 

•  Support  Equipment  Program 

<  Tast  and  Evaluation  Program 

•  LHa  Cyola  Cost  Program. 

Tha  200  Sarlas  of  tasks  ara  naoassary  for  astabllshing  raquiramants. 
Tha  300  Sarlas  of  tasks  ara  naoassary  to  optimize  tha  design.  A  novloa  dssiras  to 
know  which  tool  to  use  for  each  of  tha  tasks.  An  expert  knows  that  these  tasks 
involve  many  disciplines,  ara  fractionated,  and  that  there  ara  a  vast  number  of  tools 
and  models  from  which  to  choose.  Trade  studies  carried  out  within  tha  systems 
engineering  process  Involve  a  team  of  design  engineers,  IL8  engineers,  and 
specialists  from  various  disciplines  as  required  by  the  speolflo  subject  of  the  study. 
Furthermore,  one  model  often  will  be  used  during  the  tasks  of  establishing 
requirements  and  also  used  when  the  design  Is  optimized.  In  fact,  this  is  so  often 
the  case,  that  any  model  Included  in  this  document  under  the  section  for 
establishing  requirements  Is  also  Included  in  the  section  for  optimization. 


WHICH  MODEL  TO  U8B7 

Which  model  to  use  depends  on: 

-  The  models  Input  and  output  parameters.  Each  program  has  a 
different  set  of  priorities  and,  therefore,  the  different  model 
parameters  will  have  different  weights  of  Importance.  Certain  models 
apply  more  readily  to  some  parameters  than  others. 

•  Budget.  Certain  models  are  software  Intensive  and  are  more 
expensive  to  obtain  than  others.  Others  are  labor  Intensive. 

•  Resources.  Some  models  require  specific  host  computers. 

MIL-STD>1388-1A,  Appendix  A.  paragraph  40.6  recommends  using 
simple  models  during  Concept  Phase  and  more  complex  models  with  more 
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dftailtd  paramattrt  as  tht  dtaign  bacomaa  battar  datinad  and  a  aupport  oonoapt 
la  aatabliahad. 


WHAT  TRADEOFFS  IMPACT  DIAGNOSTIC  REQUIREMENT  GOALS? 

Upon  ravlawing  all  tha  programa  raquirad  for  LSA/LSAR  data 
aubmiaalon,  thoaa  moat  ralatad  to  diagnoatio  oapabllltlaa  ara: 

RallabllKy,  Maintainability,  TaatabllHy.  and  Support. 

What  thaaa  four  programa  raally  provida  la  ayatam  raadinaaa  or 
availability.  It  la  alwaya  daalrabla  for  mlaalon  aquipmant  to  ba  raady  and  avallabla. 
Tha  ma)or  offaat  to  availability  la  coat.  Availability  varaua  ooat  la  tha  moat  dominant 
tradaoff  In  aatabllahlng  diagnoatio  raquiramant  goala.  It  la  alwaya  daalrabla  for 
mlaalon  aquipmant  to  ooat  littla.  What  tha  ouatomar  idaally  wanta,  tharafora,  la  for 
hla  mlaalon  aquipmant  to  alwaya  ba  raady  and  avallabla  and  ooat  affaotlva. 

Both  availability  and  ooat  hava  alwaya  baan  diffloult  maaauraa  to 
aoouretaly  pradlot  dua  to  tha  oomplaxity  of  all  tha  myriada  of  faotora  that  oompoaa 
a  raal  ayatam.  Ramambar  tha  battia  that  waa  loat  for  laok  of  a  horaaahoa  nail? 
Thia  la  avan  trua  for  muHI*mlllion  dollar  programa.  To  aohlava  aoourata  pradlotlona, 
mora  and  mora  paramatara  antar  into  tha  aquatlona  and  tha  oomputatlona  baooma 
axoaaalva.  Thara  hava  baan  many  oonaolantlout  attampta,  howavar,  to  Inoiuda 
moat  raiavant  faotora  wKhout  baing  too  oomputatlonaliy  burdanaoma.  Alao,  much 
of  tha  oomputatlonal  burdan  la  aaaad  through  uaa  of  tha  oomputar. 


HOW  IS  AVAILABILITY  MODELED? 

Availability,  dua  to  Ita  oomplaxity,  la  raraly  modalad  tha  aama  way  in 
avary  datall  by  diffarant  programa.  Conaldar  tha  following  dafinitlon  for  Availability 
(Ao)  providad  by  NAVMATIN8T  3000.2  aummaiizad  balow.  (ThIa  modal  diffara,  by 
tha  way,  from  tha  ganaral  modal  providad  by  RADC-TR-79-309  whioh  aubatitutaa 
MTTR  forMDT.) 


GENERAL  MODEL:  Ao  -  MTBF 

MTBF  +  MDT 

MDT  •  MDTa  ♦  MTTR  +  MLDT  +  MDToa  +  MDTt  ♦  MDTor 
MDT  ■  Maan  Down  Tima 


MDTa  -  Maan  Down  Tima  dua  to  Schadulad  Maintananoa 
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MTTR  ■  M««n  Tim#  To  R#p«lr 

MLDT  ■  M#«n  Logistic#  D«lay  Tim# 

MDTo#  -  Av#rag#  Down  Tim#  Waiting  for  Outald#  Asslatano# 

MDTd  ■  Avarag#  Down  Tim#  du#  to  lack  of  Dooumantatlon 

MDTt  ■  Avarag#  Down  Tim#  du#  to  lack  of  Training 

MDTor  ■  Avarag#  Down  Tim#  do#  to  Oth#r  Raaaona 

Th#  aganoy  raaponaibi#  for  #«tabilahlng  BIT/ETE  •ff#otlv#n#as  goals 
should  b#  k##nly  awar#  that  a  ayatam  dasignad  with  axoallant  diagnostic 
oapabllltlas  will  substantially  raduca: 

MDTs  •  Mora  confldanoa  In  systam  ohaokout. 

MTTR  •  Raduca  FD/Fi  timas. 

MDToa '  Lass  tima  tor  outsida  anginaaring  assistanoa. 

MDTd  •  Lass  naad  for  dooumantatlon. 

MDTt  •  Lass  skill  laval  raquirad. 

Tha  trand  Is  to  ambad  mora  and  mora  diagnostio  capability  Into  tha  BIT 
function.  Incorporating  BIT  Into  a  systam  rasults  In  vaiiad  amounts  of  Inoraasad 
siza,  walght,  powar,  and  softwara  raquiramants  dapanding  upon  tha  BIT 
mathodology  usad.  Thasa  factors  must  ba  considarad  whan  making  cost  and 
parformanoa  tradaoffs  for  altamata  fast  systams. 

Soma  othar  Important  paramatars  and  oonoapts  to  oonsidar  ara  spar# 
atookaga  lavals,  tha  logistics,  maintananoa,  and  local  rapair  oonoapts,  tha  dagraa 
of  modularization,  ato.  On#  quickly  saas  that  on#  analysis  using  on#  modal  Is  not 
going  to  aoourataly  astabllsh  raquiramant  goals.  Each  paramatar  In  tha  sbova 
modal  must  ba  saparataly  analyzed  for  Its  total  content  and  how  this  total  Is 
calculated.  Assumptions  mad#  must  ba  dooumantad  so  that  whan  changes  In  tha 
assumptions  occur,  changes  In  tha  calculations  can  ba  understood.  Numerous 
operational  availability  sensitivity  analyses  must  ba  performed  to  ensure  s  high  and 
stable  Ao. 


Although  MIL‘8TD*1388>1A  defines  tha  LSA  program  raquiramants,  It 
does  not  define  tha  prooaduras/spprosohas  for  LSA  task  accompllshmant.  Raf[1] 
has  bean  developed  to  strengthen  tha  LSA  program  and  assist  In  tha 
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•ooompllthmtnt  o(  thot«  LSA  tMkt  tot  forth  In  MIL-8TD-1386-1  A.  This  documont 
oataloguoi  numorout  mothodoloolos,  both  manual  and  automatad,  that  axiat  within 
tha  DoD  and  Industry  which  can  ba  uaad  to  satisfy  many  of  tha  LSA  task 
raquiramanta  In  total,  or  In  part. 

Tha  taohniquaa.  modals,  and  programs  that  composa  Raf[1]  will  all  In 
soma  way  apply  to  tha  ovarall  taak  of  Intagrating  a  diagnoatio  capability  Into  a 
function;  howavar,  of  particular  Intaraat  ara  thoaa  modals  that  diraotly  Inoluda  a 
BIT/ETE  FOM  althar  aa  an  Input  or  an  output.  Soma  of  thasa  modals  ara 
rafarancad  In  tha  guldanoa  saotlon  of  tha  BIT/ETE  POMs  artlcla  whan  tha  givan 
POM  la  usad  althar  as  an  Input  or  an  output  to  tha  modal.  BIT/ETE  FOM 
paramatars  most  oftan  usad  In  tha  LSA  procass  ara  Availability.  MTTR,  and  MTBF. 
(BIT/ETE  affaot  MTBF  pradomlnantly  whan  fault  tolaranoa  la  daployad  In  tha 
functional  daaign.) 

Tha  following  four  pagaa  contain  a  modal  listing  that  providaa  soma 
axamplas  of  modals  uaad  In  part  to  astabllsh  Availability  or  Systam  Raadiness 
goals  during  tha  LSA  procass.  Both  tha  modal's  acronym  and  Its  full  nama  ara 
givan,  To  battar  undarstand  what  tha  modal  will  do,  a  briaf  list  of  Inputs  and 
outputs  Is  also  providad.  Mora  background  Information  may  ba  obtalnad  In  Raf[1] 
which  also  provides  souroas  for  avan  further  Information.  Raf[7]  Is  a  good  source 
for  Availability  aquations  for  redundant  systems. 


C-18 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


I . 

ACRONYM 

a.  VI  AOOLoarnoM 


1,1.1  ARIOAI* 


1 


FULL  NAME 

INPUTS 

OUTPUTS 

Army  CcmmunteallMt 

OptrtHonil  «v«NabMty 

Leaeteeelaalef  LRUi 

Opmmand  LogMkt 

gMl 

rapulrad  lor  eparlng 

TridMlIMacM 

•  • 

at  each  (He  which 

SquIpnMni  raltblty 

maaUthedaaltad 

btocAdlagramt 

operaUenal 

•  « 

avallabMIygeal 

LRU  data  eentlillao 

•  • 

el  each  LRU*  eeal, 
lalhifc  rata,  danaKy, 

Sal  d  LRU  piaraa 

raquirad  olhaRa  le 

main  dma  to  raatora 

aehlava  eS'ClIa 

ot>>iHe,  repair 

order  ntrataa 

toeatlen,  waaheut 

dailrad 

ralM,  and  predueden 

s  • 

lead  lima 

Total  eeal  el  LRUa 
aparad  par  oRa,  al 
area  aupperla,  and 
dapel 

VUpyMy  inWInSwQli 

eenalallnQ  el  order 
and  aMp  Hmaa  Irem 
dapel  and  area  mtppetla 
le  aMa  and  ott-aNa 
order  Ml  rataa 
daaltad 

ArmyLagMka 

AaSaaimnnI 

Rlylng  program  Me 
adtieh  hu  IS  Inpuli 

which  Include  mlaalefi 

1^^^^  ^^1^  ^-1 - 

lOTl^ina  VMy  H^WIp 

heuiaparalreralLcIa 

Mlaalon  auoeaaa  rala 
•  • 

Repair  coal 
•  • 

AlrardI 
avaHMIy 
» • 

Rada  data  baaawhtoh 
haa  IIS  Inpula  wNah 

Indudaa  auah 

MermaSon  aa  unh 

- > 

BBaftVaiWWW 

lead  Snta,  order  and 
ahip  Sma,  repair  eeaM, 
ale. 

•  « 

Rapalrabla  apara 
malnlalnabMIy 

ralabSliy  analyito 

s  s 

One  year  eapablly 
purehaaa  analyela 

Perea  Me  which  haa  7 

Inpula  rapulrad  whioh 
la  number  el  alrarall 

In  a  urdL  daaerlpden 
ol  unS,  ala 

C-19 


DESIGN  AUTOMATION  TOaS 


APPENDIX  C 


AQBQNYM 

2.1.3  A80AR 


INPUTS 

QMTPtfTg 

AcMavkiga 

Syttam  oparatton*! 

Whalhar  ttw  syalam 

tyilMn 

■vaNtMIty 

daaign  and  luppart 

O^iMonai 

raqUramant 

plannad  wM  a^lsva 

AvaMbMy 

•  ft 

tha  syslam  eparadanal 

Raqulramant 

Syatam  eonflguratlon 

avalliblly  raqutramanla 

wwnouuwyy 

SnO  IMm 

ft  ft 

ft  ft 

Syalam  auppett  oeneapla 

Oraas  aadmaden  al 

plannad 

tharalallvaaasifaf 

ft  ft 

taaandary  Nam  ftoaraa 

Maan  lima  le  aMaIn 

ft  ft 

anURUipara 

Oparadanal 

ft  ft 

avallabHygaala  (ar 

Ind  lam  Maan  Oalandar 

aaah  dMaraM  lypa  e< 

1  Wn9  ■OTBlWi  rMUfW 

addeal  and  lam 

(MOTftR) 

ft  ft 

ft  ft 

^lam  Maan  Oalandar 

Tima  ftalwain  RaMaa 

Ind  lam  maan  raalatad 

Mma 

ft  ft 

ft  ft 

Ind  lam  aaat  aaUmala 

Syslam  maan  raalaral 

ll(Mtlv*MOTBRa(> 
radutdanl  rwtwotfc 


2,t.40OVRRt 


a.I.IIRAMS 


2.1.3  LRAD 


OambatVstdala 

Maan  Tima  TaRapak 

Parts  naadad 

RAM  ttmuMan 

ft  ft 

ft  ft 

RartaMarmallan 

DawnSma 

ft  ft 

ft  ft 

MsIntsnAno#  mmiKMNN 

Oparadanal 

Moifnalkm 

ft  ft 

SosmHouMQtritM 

ft  ft 

•otrwrio  dama9S  ralM 

ft  ft 

Maan  l^na  baftiraan 

laHwaa 

avaHabMy 

lladranIsRAM 

RaSuraralaa 

Manpcarar  rsftulramanis 

SknUaUsn 

•  • 

ft  ft 

Rapakllmsa 
•  • 

Parts  rarpiramanls 

ft  ft 

MalMsnanoa  manpessar 

Dawndmas 

avaNMIy 

ft  ft 

ft  ft 

Oparadanal 

Usagaralsa 

avalMHIy 

Laglsdas 

Ralablly  bhxft 

Syslam,  subsystam,  and 

Inginaaring 

diagram  nWi  aach 

blael  rallabMy 

Analysis  ol 

blaek’s  lallura  raiss 

pradledans  lar  user 

Daaign 

ft  ft 

spaoHlsd  dma 

MTTR 

ft  ft 

imarvala 

ft  ft 

Ptsvanliva  malnlsnanea 

Syslam  MTBP 

ft  s 

pelley 

ft  ft 

Syslam  Mean  Tima 
Balwaan  Unsehadulad 
Mahulananea  MTBUM 

Numbar  el  haurs  par  day 

ft  ft 

lha  syslam  oparaSas 

Avalablly 

DESIGN  AUTOMATION  TOaS 

APPENDIX  C 

AS5QNYM 

PUttNAME 

INPUTS 

OUTPUTS 

2.1.7  LSSA8 

Logliliei 

Tha  RMdal  ean  ba 

In  lotma  el  lortle 

mil) 

Support 

axarolaad  In  a 

rata  In  reapome  to 

Slmulalor  ler 

paramairte  laaNen  evar 

varladena  el  Input 

■ 

AkeraH 

Syttamt 

awWofangaolInpul 
dala,  Indudlno! 

S  • 

Vafladena  el 

MTIS.Mrm,  No! 

OparadonaHy  Ready 

Supply  (MORS)  rataa, 
and  ATB  eapablllly 

S  S 

Pramighidurallon, 
launch  aaSvMaai  taxi 
and  ood^'rtinway 
ehack.  anbibHv  el 

an  Twiffac  Bdv  aMrvarMMv  W 

sroundandali  abort, 
aortia  and  peaimiphl 
duration 

S  S 

Sehadidad  malnlananoa 
Intarvalandduratlen 

«  s 

Spate  data 

data 

2.1.1  onsM 

OparaSoiwI 

RaldCMy, 

Daly  laHng  ol 

naadbOM 

maIntalnaWIty, 

■SwSlI  rWraHIMS 

■valuation 

aupport,  and  mMon 

data  In  tarma  ol 

Mod#| 

oaMnalaa 

avoHabMy,  aMly 
teBalWylhemlaalen 
raquiromens,  and 
iortteralaa. 

S  S 

•  parti  rtaliy 

•  alreraft  net  MIy 
•9«lpp*rt 

•  dniiyi  In  prevMng 
Oreund  Support  fc^uli^ 
mant 

■  Hmo  ipont  In 
mekrtananee  ihepa 
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HOW  MUCH  WILL  IT  COST  7 

Th*  grand’daddy  coat  to  consider  la  the  LHa  Cycle  Cost  (LCC)  or  the  total 
cost  to  acquire  and  maintain  mission  equipment  throughout  Its  life  cycle.  LCC 
studies  are  performed  against  a  fixed  availability  goal.  LCC  elements  are  divided 
between  development  cost  elements  and  operating  and  support  (O&S)  cost 
elements.  The  following  are  typical  development  LCC  elements; 

•  Equipment 

•  System  Test  &  Evaluation 

-  System  Engineer/Program  Management  (non*ILS) 

•  Data  (non>ILS) 

-  ILS 

•  Industrial  Facllltlea 

•  Test  Program  Sets. 


The  following  are  typical  O&S  LCC  elements: 

•  Personnel 

•  OO'SIte  Equipment  Material 

•  Direct  Depot  Maintenance 

•  Sustaining  Investment 

•  Software  Support 

•  Contractor  Sustained  On-SIte  Support 

•  Recurring  Publloatlons  Cost 

•  Indirect  Equipment  Costs. 

LCC  models  can  prove  to  be  very  valuable  cost  saving  decision  making 
tools.  Ref[6]  uses  the  USAF  Logistics  Support  Cost  (LCS)  model  to  make  a 
comparison  of  test  effectiveness  with  and  without  a  testability  program.  This 
reference  shows  an  example  of  a  $4,400,000.00  savings  when  a  15>year,  60-unlt, 
continuous  operation  Is  deployed  with  testability  considered  up  front  as  opposed  to 
not  considering  It. 


Ref[5]  Is  a  first  source  for  LCC  models.  Each  reference  will  contain  LCC 
model  description  information.  The  following  three  pages  provide  some  Information 
to  some  LCC  models  available.  Please  note  that  the  criteria  for  listing  them  Is 
simply  that  Information  concerning  them  was  readily  available  and  that  they  are 
listed  only  to  provide  examples. 
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ACRONYM 

FULL  NAME 

INPUTS 

OUTPUTS 

8.1.0  PlEXe 

ThaMlIv* 

Apprwlmalaly  80 

Total  LSO  wMh  vaileua 

looMe 

VMapenand 

epilona  aa  to  how  thay 

•  •  0  • 

•uf9(>arteMt 

■ytlam  Irput  variablat 

ara  otaaaHlod  and 

8.1.10  LSC 

modalno 
•yMami  won 

Aipprax,  80  Input 
variablaa  par  night 

diaplayad 

«  «  •  • 

2.1,11  LCCATM 
{ADA; 

LCOA) 

•  *  *  « 

8.1.18  FAMILY 

OP  LOG 

MOOB.O; 

LOO -8 
•SA.  -10, 

•AT.  Ble. 

•  •  •  • 

8.1,10  TRITAC 

rMpMlhily 

d«MtofMdby: 

•Navy 

-APALaOCTXO 

•  AnalyHaol 

SdanflMOoip. 

fTAOO) 

-Oapt.o1 

AlrPoroa 

•  Bintagto 

Pinandai 

PlamlnB 

Syatama 

llnaunft 

8,1.140O8TPRO 

Oo«Prc)adlen 

Support  ham  coat  and 

Summary  by 

Managamant 

maMananea  eedaa 

appreprladen 

Inlonnallon 

•  • 

S  • 

Syalantlor 

Moan  Tima  To  Rapalr 

Coat  and  funding 

LNa  Cyota  Ootta 

•  • 

MaanTVnaltlwoan 

PaMuraa 
•  • 

Rapair  turnaround 
dma 

•  S 

Supply  and  maMananoa 

hiarwehy 

•  • 

MUSIEUIliy  raSfWBnf 
•  * 

Rapair  labor  eoala 

s  • 

Support  aqu^pmant 
trairilngaiid 
doflumantaMon  ooala 

raaponaMfey 
raperi  Alraporta 
praducOdalnbaaa 
yaarorMlaM 
dellara 

S  • 

Ooataummaryraport 
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ACRONYM 

2.1.1SLOCAMS 


2.i.iaioaAM 


EybkMME 

INPUTS 

OUTPUTS 

uuyviiuv  wMv 

AppfM(lnwMy92BLRU, 

UlB  Cyeto  Cod  d 

ArwIyaltMetM 

dBptoyfMnli  Bnd  Mfninon 

ownaraMpler 

Vwiton  B 

itandvd  eed  taelM* 

MlvIduolURUo 
•  * 

Coot  totoli  lor 
cporodngond 

malntonaneo 
•  « 

Inharad  and 
eparatlenal 
•vaDoblBy  at  both 

LRU  and  ayatom  lavala 
•  • 

Manpoatof  raciubatnanta 
•  • 

PrevPkifdng 

rac|ulfaittanla 
•  • 

Taat  aquipmant 
roqUramanta 

LogMet 

Ar.nKkMMyMSLRU, 

Lba  Oyola  Cod  ^ 
lha  ayatom  and  WdMdua 

AntlyttaMocM 

dBpleymtnl,  and  e«nwwn 

« • 

LRUo 

Up  to  200  TtM*  el 

(b  • 

0«g«nluBM  (TOI) 

OAMeoda 

tatotodvaitoMM 

•  • 

OAdaoala 

tppioBlIcn  RMQf  bo 

•  • 

InpultooMiln 

AvalabMy 

OAteoBli 

•  • 

•  • 

Manpotoat  taqybamanla 

lUpalrBm* 

> » 

•  t 

PfowWonliiQ 

PailMnnia 

raqubatnanla  and 

•  • 

aupport  aqdpmanl 

Falwtolur* 

uoagoaiaprovdad 

•  • 

AMBoniito 
•  • 

Mtnpoww  by  lypt  aind 

r«lM 
•  • 

9up|dy  faolpw  wd 
support  ocate 

IndwoUp^ 
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ACRONYM 

PULL  NAME 

INPUTS 

OUTPUTS 

a.1.17PRIOEi 

ParemeOte 

PRIOR  H  Inputa: 

Ratimalaa  LOO  oeala 

POUR 

Review  et 

daaign  eeneapt 

for  a  variety  of 

RIUtTSD 

IntomiMten 

doa^den:  alie, 

ayalema 

PROaRAME: 

toreeaUno 

weight,  eemperwnt  typo. 

•  H 

•ndSvtiuMlen 

power  diaalpatlon,  alo., 

PRIOR  H'. 

•  8 

(PRICI) 

elaaatflad  aeeerding  to 

eoeteadmalleneflhn 

•  Ht 

weighting  laelera 

OVWOpfIvViL 

•  8L 

Hi  hardware 

arMeal,  Ifflpertant) 

produellon,  anchor 

HU;  Hardware 

medHIoatlen  el 

LOO  Modal 

PRIOR  HLInputa: 

hardware 

•:  toltwara 

*  Igulpmont  Dependant 

•LSallwaro 

•MTIP 

PRIOR  HU 

LOO  Medal 

(Oevolapadby 

ROA] 

‘MaanRapakTInMO 
*HDWI  eeata,qtyt., 

IMUfinQ  QIEWE 

ter  ae(|.  R  at^ply 
*OoM  at  laM  equip. 

*#af  mcdutaaR 
parte  par  unit 

eoot  eattmallen  of 
aueply  and  maintenanoa 
el  hardware  lyatarno 

PRIOR  Ri 

eealoelltnalleneftha 

Mae  imI w  iwe 

OWWpfWnL 

preductbn,  andler 

*  Oaptoynaid  dependant 

medMeatienel 

(U.R.,  Rurape.  SR 

loltware 

Aalei  Mae  muat 
apeelylhei 

efInaliilMlone) 

PRIOR  RIJ 

OoMeatin'allenel 

*  fffflpleyinent  deperrdent 

lupply  and  .waltdananee 

(Re^lroquanoyt 

el  aoRware  ayMema 

fftqu>njy  p> 

•  OtpsfilBsIlQvi  dipilidMl 
*  H  fnsinISAAnM  wl 
locflttom 

^  SfMMiflO  OOfMMBtS 
poMktoforHDWI 

finlV^PIWIPV 

'UniqwhwIartttMl 

W^pff  IPW  IfWOTO 
Ql  VI 

ofOMtultan  (l«., 

fWUfiplyt  lllTMi  MWpi 

WMr  ratM,  Me.) 


PRIOI  Dele  iM*  ter  one  PPIOI 

8ASL  Pfegnmeenbeeenledevw 

to  Mtior  PPIOI  vorMeia. 
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HOW  MUCH  SUPPORT  EQUIPMENT  AND  MANPOWER  WILL  WE  NEED? 

A  major  task  of  tha  LCC  analyaat  la  known  as  tha  Laval  of  Rapalr  (LOR) 
analysis.  LOR  analysis  rasults  In  astabllshInQ  raquiramants  in  two  major  araas, 
sparing  and  manpowar.  Tha  TFOM  raquiramant,  which  Idantiflaa  ambigultlas  (falsa 
pulls),  will  also  Impact  thasa  araas.  Typical  tradaoffs  mads  whilo  doing  an  LOR 

analysis  ara: 


•  Support  aquipmant  vs  sparing  raquiramants 

•  Whara  Is  tha  rapalr  mada? 

•  Rapalr  and  Raplaoa  (R/R)  task  daacriptions. 

Thara  ara  many  modala  from  which  to  ohoosa  for  performing  an  LOR 
analysis.  Tha  following  two  pages  provide  soma  information  to  aoma  LOR  analysis 
models  available.  Note  again  that  tha  criteria  for  listing  these  particular  models  Is 
simply  that  Information  concarnlng  them  was  readily  available  and  that  they  ara 
listed  only  to  provide  axamplaa. 
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AgPQMY^ 


2.1. II MOD  III. 
Lon 


a.I.IINRUk 


I.1.MOAIM 


2.141  OIAMM 


J 


FJtfJaLNAMB 

INPUTS 

QMTPVTS 

Laval  9>  Plapalr 

Analyah  Medal 

PtiftiiiDtd  to 

muii 

MIL-2TD-1IMI 

Afpandta  A 

Paramatara  el  WnA't: 

MTIP,  Mrm,  walgM, 
ale. 

l/Dapol  loval  logMIo 
aup^ooala 

Davalapadby 

NAVAin 

nvpvia 

Laval  AnalvNa 
(AFALCMCM* 

(WPAn) 

Waapert  ayalam  data 
(l.a.,  fbaaaa, 
ayaiam^aaaa, 
oparalnt  hawa), 
laglalea  data  (l.a., 
labarralaa,  lam 

tfiMMitoltofI  fMlMlk 

MMJtoHIMl  ^to 

(l.a.,  coal,  avaMiMy) 

LIU  A  2101101011(1.0., 
taMura  ratal  rapair 
dma) 

IVWI  BVSWBfi 

f^^WvnffWwBBOIvBa  w 

iBtoHtoM  soBti 
dstoUsdfsHf  tovt 

- a 

WaWlamjr 

analyala  Mormallan 

Oparadana  ar«d 

■TTTWWI^MH 

•yndtaaii 

A^llpMheura 
•  • 

WIUdtRAMM 
•  • 

laraamwIaMI 

BB  fBBUVWnWW 
•  t 

WfUUIRATAT 
»  1 

AvaliMMy 
•  2 

HoaoureaulMullMt 

2  2 

•paraa  avalabHly 

Avalatdaiidlloval 

and  II 
•  • 

VBB  •BBaWiV 
«  • 

•paraa 

Opiwum 

Ar»r 

MaMananaa 

MaiuMi 

I/M  data  (MTId,  Wapab 

Tima) 

•  « 

SUOOBfl  BOUtotTUnt  BOii 

«  a 

wtophi  flfto 
sotl 

Malntarwiwa  2  ropab 
laah  dMilullen 

2  2 

AvalMly 

2  2 

•paring  lavala 

AvtliMsIaigM 
•  • 

MWaiyOoou^tltofwl 
•pMlally(MOI)iM 
l•v•l  and  labor  rata 
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AOEOftcag 

FMLLNAMB 

iMPAm 

OUTPUTS 

a.iJaaiBAMi 

SyvlBfn  BtployTBiBl  by 

Sparing  tavali  at 

IMWIIW- 

yMf  MdloMaen 

aaotiauppert 

HuaiPthmi 

•  • 

BObstOA 

lorAvOMt 

Tumaraund  Him 

•  • 

Talal  ipafat  eoal 

UJ.AimyOIOOM 

n«palrlMt( 

bIlirtbubdB 
*  * 

MalnMnwiMlMk 

*  • 

Ofd«rat#UnM 
*  • 

ni^w  viw 
•  • 

FaMurntMlor 

S  f 

Avtls^ 

BsNsvsd 
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A  major  task  of  LCC  analyiaa  It  maintaining  and  updating  a  data  base 
with  tha  abundanoa  of  data  ganaratad  during  tha  procatt.  Thia  maant  that,  aoontr 
or  latar,  paraonnal  muat  alt  down  and  rtcord  a  largo  number  of  the  rolovant  faota 
onto  a  aproadahaot.  Tha  apraadaheat  may  phyaloally  ba  mada  of  paper,  or  It  may 
be  computer  prooaaaad.  Tha  oomputar>aaalatad  varalona  offer  oonvanlant  data 
aooaaa,  which  make  them  much  more  daairabla.  Of  what  uaa  la  an  Important, 
daolalon-making  plaoa  of  Information  that  la  burled  under  a  ataok  of  apraadahaata  or 
In  aoma  duaty  file  oablnat? 

To  maintain  oonalatant  oommunloatlona  between  dapartmanta  and 
programa,  tha  government  haa  aatabitahad  MIL*STD- 1388*2 A  whioh  providaa  tha 
formate  to  record  LSA  data. 


Two  popular  maana  of  fulfilling  MIL*8TD*1388*2A  raquiramanta  via 
programa  that  offer  oomputarixad  aaalatanca  are  Hated  below. 


AfiBgMXM 

EUkkUMIE 

iMEm 

l.t.tlOALSA 

Osfwwlsf  AMmI 

Mll..aTMSM.SAIifUl 

AIMII.STD.1IM4A 

If 

4eie  ilwili 

fSvnW  wIVi 

fnOTRJfWiP  WIS 

wpanillnt 

t.1.S4llAOa 

L«|M«anW 

■nSAnalyai 

M14T0>1SM-Udita 

S^SR^SR^S 

9hmu 

2.2  AllooaSon  Toola 

Tha  requirement  toola  of  thia  aaotlon  have  ba  oatagorizad  with  tha 
following  aubhaading; 

•  Allocation. 

Praaantly  tha  predominant  toola  for  thia  taak  are  military  atandarda. 
Rafaranoa  la  firat  mada  In  Table  8  (Requirement  3.1)  which  mantlona  four  military 
atandarda  that  help  provide  tha  dafinitlona  of  what  la  maant  by  allocating  diagnostic 
capabllHIaa.  They  are:  MIL*8TDa*499.  *785,  *470,  and -2166. 
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8lno«  th«  tMtno*  of  tytfom  roadlnott  it  ttauring  that  t  ftuMrtt  Htm  Is 
avtiltbit,  many  of  tha  daolaiona  within  tha  atturanoa  branch  of  anginaaring  art 
baaad  on  tha  faliura  rata.  Tha  fallura  rata  la  tharafora  pradlotad  firat  and  all  other 
aaauranoa  goala  and  paramatara  follow.  Wa  look  to  MIL*STD>7MB  for  diraotion  aa 
to  how  to  dariva  tha  fallura  rata.  Of  partloular  Intaraat  In  thia  atandard  to  thoaa 
eoncamad  with  allocating  taatabilHy/dlagnoatio  raquiramanta,  la  Taak  102.  ThIa  taak 
dafinaa  and  diaouaaaa  how  to  oonatruot  a  miaaion  rallablllty  modal  (2.3  A  2.4)  and 
laya  tha  foundation  for  tha  following  modeling  oonoama: 

•  A  definition  of  parformanoa  paramatara,  aa  wall  aa  phyaloal  and 
functional  bouridariaa. 

•  A  definition  of  what  oonatitutaa  a  fallura.  Including  mlaalon  orltioai 
thraahoida. 

■  A  definition  of  tha  environmental  oonditiona  and  tha  parloda  of 
operation.  Poliolaa  oonoarning  uaa  of  redundant  equipment  are 
Introduoad  hare. 

•  A  definition  of  miaaion  time. 

•  A  definition  of  tha  reliability  vartabla  of  tha  Ham  alamanta. 

•  Tha  Mlaalon  Reliability  blook  diagram,  a  plolortal  form  of  a  atatamant  of 
what  la  raquirad  for  mlaalon  aucoaaa.  Several  blook  dlagrama  may  be 
davalopad  whan  raquiramanta  are  not  flnn. 

Referring  onoa  again  to  tha  200  A  300  Sartaa  of  taaka  of  MIL*8TD'1386* 
1  A,  It  la  apparent  that  there  are  oarlain  aubtaaka  that  are  Indudad  to  make  baaallna 
oompaiiaona  of  almllar  ayatama  and  perform  a  Laval  of  Repair  analyala.  DIagnoatIo 
raquiramanta  should  be  allooatad  In  a  manner  that  la  familiar  to  tha  uaar.  Thia  la 
aooompllahad  (In  a  roundabout  way)  by  performing  a  baaallna  oomparlaon. 
Juxtapoaad  to  making  baaallna  oompaiiaona  are  tha  aHamatlva  and  LOR  tradaoffa. 
Determining  at  which  level  tha  diagnoatloa  are  to  be  performed  la  almllar  to 
determining  where  tha  repair  la  made,  in  other  worda,  tradaoffa  made  In  order  to 
properly  allocate  tha  diagnostic  oapabllHiaa  to  tha  varloua  repair  lavaia  are  almllar  to 
many  of  tha  tradaoffa  performed  during  an  LOR  analyala.  Rafaranoa  will,  tharafora, 
be  mado  to  tha  guidance  provided  in  Section  2.1  of  thia  appendix,  titled. 
*Eatabiiahlng  Raquiramanta".  Many  of  tha  modala  mantlonad  In  that  aactlon  will  also 
help  allooata  diagnoatic  raquiramanta. 

Currently  tha  Roma  Air  Davalopmant  Canter,  In  conlunotlon  with  tha  Army 
(CECOM),  la  developing  methodology  to  perform  diagnoatic  allocation  while 
accounting  for  factors  auch  aa  coat,  weight  and  oomplaxity.  Final  documentation  of 
this  program  will  be  available  from  RADC  In  aarty  1900. 
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2.3  Optimiutton  Tools 

Ths  rsqulrsmont  tools  of  this  ssotlon  hsvs  bssn  ostegorizsd  with  tho 
following  subhssding; 

•  Optimizstlon. 

Rsfsr  to  ths  ssotlon  contsining  rsquirsmsnt  tools  with  ths  subhssding, 
"Estsbllihlng  Rsquirsmsnts*  (Gsotlon  2.1  of  this  Appsndix).  Ths  sams 
tools  srs  ussd  to  optimizs  ths  dssign. 

2.4  Risk  Asssssmsnt  Tools 

Ths  rsquirsmsnt  tools  of  this  ssotlon  hsvs  bssn  ostsgorizsd  with  ths 
following  subhssding: 

•  Risk. 

Upon  rsviswing  ths  200  &  300  Ssriss  of  tssks  of  MIL*8TD*13e8*1  A,  It  Is 
sppsrsnt  thst  thsrs  srs  osrtsin  subtssks  whioh  srs  Inoludsd  to  smssi  risk.  Ths  two 
msjor  sipsots  st  risk  to  sny  progrsm  srs  ths  risk  of  s  suoosssful  mission  for  which 
ths  progrsm  wss  Intsndsd,  snd  ths  risk  of  dspisting  ths  finsnoss  thst  support  ths 
progrsm.  Csrsful  sttsntlon  to  mlnimizs  ons  of  thsss  msjor  risk  fsotors  oould  dlrsotly 
osuss  ths  othsr  to  spprosoh  s  msximum.  In  ssssnos,  minimizing  risks  Is  psrformlng 
Avsilsbillty  vsrsus  LIfs  Cyols  Cost  trsdsoffs  In  rsistlon  to  dsvsiopmsnt  sohsdulss. 
Rsfsrsnos  will  thsrsfors  bs  msds  to  ths  guldsnos  providsd  In  ths  ssotlon  with  ths 
subhssding  *Estsbllshlng  Rsquirsmsnts”  bsosuss  msny  of  ths  modsis  msntlonsd  In 
thst  ssotlon  will  siso  hsip  mlnimizs  risk. 

Rsfti]  doss,  howsvsr,  list  thrss  modsis  thst  wsrs  spsolfloslly  dsvsiopsd  to 
ssssss  risk.  Thsy  srs  llstsd  bslow. 
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AQB9N.Y.M 

f:.yi.L>!AM6 

iMLyrs 

QIJTPVTS 

84.1  SISNIT 

TweaeSyMy 

ptfamaltni: 

•  THtw 
•Oatl 

PtcSibaiy  e( 

BUWWIyWnlf^  wW 

pcogranw  •Kart  v«. 
Ilmacoal  •  •  tout 

pragram  aflort  Of  1 
MQnwiI  o1  on  oflofi 

rVOQV  fwf 

•onMnlnf  mSvWm 

Ora«tl  path  tor 
•ttooduto  and  ootl  or 
oltoar  paramolara 

1.4.8  TXAOl 

TaUIMat 

aaitiwit 

Co«lMUnMMBfi 

prabaWaiMtnd 

PtaMbMyolitotu 

l.4.STaAOI>P 

ToMaM 

AiBBBilnf  ObbI 
liHmtto 

P  a  PfaSuiSan 

rvBmMVBn  TBWiBQ  nsn 

tMlm  ().•„ 
in>»aduliii).  otrti, 

V 

OaotStotribuSoM 
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3.0  DESIGN  IMPLEMENTATION  TOOLS 

This  section  lists  software  design  systems  as  well  as  a  variety  of  other 
tools  that  are  either  available  or  under  development  to  aid  In  the  design  and 
development  of  an  effective  diagnostic  system. 

These  design  Implementation  tools  have  been  categorized  with  the 
following  three  subheadings: 

•  Architecture 

•  Design  Rules  and  Practices 

•  Diagnostic  Authoring 

•  Diagnostic  Test  Strategies 

•  Automatic  Test  Generation  (ATQ)  or  Automatic  Test  Program 
Generation  (ATPQ)  [Generating  Digital  Test  Vectors] 

There  are  no  claims  made  that  this  is  an  all  Inclusive  list  of  the  tools  that 
In  some  way  aid  the  task  of  designing  and  developing  an  effective  diagnostic 
system.  There  are,  perhaps,  dozens  of  tools  that  are  not  Included. 

It  may  be  well  to  note  here  also  that  SIT/BIT  circuitry  is  designed  and 
developed  almost  exactly  In  the  same  fashion  that  functional  circuitry  Is.  Therefore, 
the  same  tool  aids  that  are  targeted  for  functional  design  and  development  may  be 
listed  In  this  section.  A  feature  that  SIT/BIT  designers  seek,  however,  Is  the 
capability  to  design  hierarchically. 

A  summary  and  listing  of  all  tools  included  In  each  section  Is  provided  at 
the  beginning  of  each  section. 

The  entries  that  follow  In  each  summary  are  listed  In  alphabetical  order. 
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3.1  Arohlt«etur«  Tools 


Tools  that  aid  In  tho  architooturti  doaign  and  davalopmsnt  of  an  effactivs 
diagnostic  capability  llstod  In  this  saotlon  all  hava  tha  following  faaturas  in  common; 

-  Thty  ars  ussful  during  mora  than  ona  acquisition  phase  and  apply  to 
more  than  ona  laval  of  Intagratlon. 

•  Thay  apply  to  a  variety  of  hardware  taohnologiss,  including  analog 
and  digital  circuitry. 

-  Thay  are  all  versatile  and  capable  of  many  design  assist  functions 
Including  assisting  In  tha  design  and  evaluation  of  a  diagnostic 
capability. 

A  summary  description  of  tools  that  aid  in  the  architecture  design  of  a 
diagnostic  capability  follows. 
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ACRONYM 

APPLICATION 

PRIMARY  DIAGNOSTIC  COMMENTS 
DESIGN  ASSIST  FUNCTION 

ADAS 

VLSI/PCB/ 

srr/BIT  eptlnilulion 

PafteIVSO  (VH8IC 

SubtytlanV 

fnohNSng  MtrareMeal 

SBeon  Complaf) 

SyalMM 

hvdwar*  S  taMwart 
dMlgn 

Tool  Sat; 

TBA  waa  davalepad  to 
bo  uaod  with  ADAS 

AA.IOB 

VL8I/P0B/ 

Potm*  an  ouMna  lar 

AA.ICI  oan  Intadaoa 

SubiyilMY 

an  Initgralad 

with  divarao  oaport 

SytlMiY 

Oanaaptual 

ayalamo  ragardlaaa  ol 

Syttomef 

InvIranmanI  (lOR) 

kiKMtodgolonTtai, 

SyatMM 

raquifad  to  IniplanMnI 

OAUSphkaaphy 

languagaor 
atruoturoa  Involvod 

OACVBtr 

fOB 

ifi^wnwnwig  otw 

taat  onto  KSa 
oonyaaadot 
tunawfMl  aSouBy 

ThaOAtyBITRbriry 

HARiAlM  iMhnlOMiM 

that  oan  ba; 

•  atiMturad  or  Ad  Hoo 

•  Digital  or  analog 

•  HW.SW.orboth 

•  Oonaunanter 
non>oonaunonl 

OADATS 

VLSI/POS 

Paul  StmutaSeni 

THHSIUSATOj 
auipparta  d^ilal  HW 

KTdaalan 

Poat  groeaaa  aSwul 
lor  taigat  taatar 
oaraBatblWy;  much 
apa^  Inoraaaa  with  0/ 

AOttitAntof 

aaa^i^pnrf 

DAISY 

VLSIPOB 

OTAiaufiporta 

dl0lalMoniraNaol 

HWSrrdaolBn 

Popular 

IDSS 

VLSI/fG» 

ProvMaa  thoaa  loeta 

Prowldaa  tha 

SubvyvItfiV 

iwoaaaaty  to  anouro 

eapabMty  to  daoign  a 

Syttom 

ancdtMiod 

dlagnaaSaaapabty 

oomplata  aippoit 
ayatamlerthalul 

Ilia  eyoia  Ola 
lunoUonal  daaign 

lASAR  vin  S 

VLSVPOB 

juDai  s  ppoteouroni 
auppotta  Nararahleal 
dlgRalHWBrrdaatgn 

PootprocaaaolATO 
admiM  lor  taigat 
taatar  oomp^llty 

MINTOn  OKAPHIOS 

VLSI/POB/ 

SubvyviloV 

QUIOKPAULTi  aidipeito 
hlorareMoal  digital 

HWStTdaatgn 

Popular 
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ACRONYM 


MIDA8 


MIMOLA;  MMST 


SILVAn-LISCO 


8PIOB/PSPIOE 


J 


APPLICATION 

PRIMARY  DIAQN08TIC 

COMMENTS 

DESIGN  ASSIST  FUNCTION 

VL8l/PO» 

STAPANi  tunwiti 

Bootloilmlarlo 

SubtyMtnV 

bottom  up  dMignot 

A  oomptIMo  with 

SytlM 

OtglUliytlom 

boundtiy  Mon 

dtognooboi  utkig 

iMRt  teehnAtfiov 

toohnology 

Vl$l/PCB/ 

AutomittoSoVToot 

Optlmlxot  lottabNty 

Progmn  OonoraUofl 

and  Coot  tradooltt; 

8yilan> 

Inmioroof  machlno 
oodo 

ropotia  poor  CY  A  OY 

vuipce/ 

8k«ppod>  Moweblool 

Thorough  aoAwart  tool 

ouDsyiwfiw 

Snr/llTdoilgn 

support  drtoughout  tho 

Syitm 

dosign  prooaoai 
appftablBtodlM 
ancVor  analog  da  sign 

VLSI/POB 

Suppofto  Ad  Hoe 
•noloB  HW  BIT  dodgn 

Popular 
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3.1.1  ADAS 

NAME:  ADAS  -  Architecture  Design  and  Aseeasment  System 
YEAR:  1988  (basic  phase  prototype) 

FUNCTION:  ADAS  provides  high-level  system  design  and  analysis  support  with 
capabilities  to  functionally  model  both  hardware  and  software  together.  Using  the 
ADAS  graphical  Interface,  the  software  and  hardware  designs  are  created  together, 
analyzed,  and  refined  until  the  system  goals  are  satisfied.  In  addition  to  a  graph 
editor  and  a  consistency  checker,  the  ADAS  tool  set  consists  of  the  following  seven 
modules: 


-  Software  Data  Flow  Graph:  The  logic  and  data  flow  of  the  conceptual 
algorithm  Is  represented  with  colorful  squares  and  rectangles  (nodes) 
connected  by  arcs  (data  flow).  Individual  nodes  can  be  expanded  In 
the  same  manner,  supporting  hierarchical  software  design. 

•  Petri  Net  Simulator:  Simulates  the  Software  Data  Flow  Graph 
verifying  that  the  sequence  of  execution,  the  amount  of  data 
generated,  and  the  execution  rates  are  all  do-able. 

-  HDL  Generator:  Constructs  an  HDL  (hardware  description  language) 
program  to  simulate  the  hardware  design  using  the  structure  Imposed 
by  the  Hardware  Configuration  Graph  and  the  behavioral  Information 
contained  In  the  library  modules.  Versions  are  currently  available  for 
Helix  and  ISPS.  A  VHDL  version  Is  under  development. 

-  Hardware  Configuration  Graph:  Supports  hierarchical  hardware 
design  with  a  unique  ability  to  model  a  hardware  Implementation  of  a 
software  algorithm. 

-  Petri  Net  Analyser:  Generates  a  report  containing  performance 
statistics  enabling  one  to  determine  if  the  design  meets  performance 
goais  defined  In  the  system  specification. 

-  Software  Functional  Simulators:  Constructs  a  program  that  allows 
simulation  of  software  routines  associated  with  nodal  structure 
Imposed  by  the  Software  Data  Flow  Graph.  During  graph  simulation, 
each  node  will  be  able  to  process  Inputs  and  provide  outputs. 
Versions  are  currently  available  for  C  and  Ada. 

•  Software  to  Hardware  Mapping:  Promotes  efficient  hardware  design 
by  mapping  the  software  graph  onto  the  hardware  graph,  exposing  any 
deficiencies  or  excesaiveness. 
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CAPACITY:  N^A 
CPU  TIME:  N/A 

APPLICATION:  VLSI  ESi  SUftSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N  ^PRTY) 

DESIGN  ENV:  ADAS  Is  eomplemsntsd  within  a  complata  graphics  anvironmant  and 
also  requires; 

-  a  tape  drive  for  Initial  loading  of  ADAS  aystam  distribution. 

•  a  recommandad  minimum  working  memory  spaoa  of  3  Mbytas. 

•  a  raoommandad  minimum  disk  storaga  capacity  of  10  Mbytas. 

The  following  hardware  platforms  provida  most  elements  required  tor  the  ADAS 
environment: 


any  VAX  or  MIcroVAX 

Gould  PowarNoda  9000 
Apollo  modal  660 
(and  others) 

Sun-3/1 60C 
VAJCstation  ll/GPX 

Color  Vax  Stn  2000 


OoeratlnQ  System; 

VMS.  UNIX  BSD  4.3.  or 
ULTRIX  (Berkeley  4.2  UNIX) 
UTX2.0 

DOMAIN/iX  Version  9.5 
UNIX  3.2 

VMS  4.4  or  higher  or 
ULTRIX  1.2 
VMS  or  ULTRIX 


ADAS  marketing  can  provida  information  on  cost-effective  and  functional  system 
configurations  and  can  assist  with  hardware  procurement. 


CIRCUIT  DESCRIPTION;  The  design  is  created  and  captured  on  a  hierarchical 
graph  display  that  can  be  printed  out  In  graphical  or  tabular  form. 


USE  PREREQUISITE;  The  user  must  provide  conceptualized  high-level  Inputs  of 
the  function  to  be  designod. 


DEVELOPER:  Research  Triangle  Institute  (RTI) 
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COMMENTS:  ADAS  Is  part  of  an  avan  largar  tool  sat  known  as  VSC;  VHSIC  (Vary 
High  Spaad  Intagratad  Circuits)  Silicon  Compllar.  VSC  Is  prsdomlnantly  composed 
of  ADAS,  VHDL,  and  Qsntsll.  and  aids  In  the  design  process  from  system 
specifications  to  mask  making  In  the  fabrication  stage. 

TEA,  Test  Engineers  Assistant,  listed  In  this  section  Is  also  a  product  of  RTI  and 
was  developed  to  be  used  In  oonjunotlon  with  ADAS. 

REFERENCES; 

ADAS  Marketing  Coordinator 
Center  for  Digital  Systems  Research 
Research  Triangle  Institute 
P.O.  Box  12104 

Research  Triangle  Park,  NC  27709 
(919)  641-7436 
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3.1.2  AA.ICE 

NAME:  A/LICE  •  ADA/LATTICE  Intfgrattd  Conotptual  Environment 
YEAR:  1985  (first  operational  version) 

FUNCTION:  The  CALS  philosophy  Is  to  pool  the  knowledge  of  all  the  departmental 
experts  so  that  planners  of  a  new  weapon  system  get  as  much  of  the  big  picture  as 
possible  and  thereby  greatly  enhance  system  efflolsnoy  and  the  probability  of 
success.  The  CALS  knowledge  base  requires  "super*  representation  scheme  due 
to  the  fact  that  it  must  contain  diverse  speoialties  and  often  competing  "llitles," 
Including.  RMA,  ILS,  Support,  Design/Build,  Planning  and  Technical  Documentation, 
and  others.  This  super  representation  scheme  is  called  an  Integrated  Conceptual 
Environment  (ICE). 

The  Immediate  problem  of  Implementing  such  a  philosophy  Is  trying  to  standardize 
upon  the  knowledge  representing  formats,  knowledge  that  must  somehow  be  linked 
to  text  and  graphics  and  also  to  the  various  expert  systems  emerging.  A/LICE  Is  an 
Ada  coded  program  with  knowledge  lattice  extension  operators  to  form  an  outline  for 
such  an  ICE  and  to  provide  a  method  of  machine  hosting  ICE  morphologloal 
operators  In  Ada.  A/LICE  thus  presents  a  solution  to  processing  the  massive  and 
diverse  knowledge  requirements  of  the  CALS  program.  A/LICE  has  the  following 
features: 


•  A/LICE  can  Interface  with  diverse  expert  systems  regardless  of 
knowledge  format,  the  language,  or  structures  Involved. 

•  At  the  meta>level,  A/LICE  sees  knowledge  objects  in  lattice  arrays 
which  can  be  processed  using  standard  math  array  processors. 

•  The  A/LICE  high’level  Instruction  set  will  Interface  witir  the  emerging 
eleotrooptloal  analog  computers  that  will  use  direct  capture  "Image  as 
knowledge"  processing  techniques. 


Refer  to  the  section  2.0  of  this  appendix  for  testabillty/dlagnostic  requirement  tools. 
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3.1.3  CAD/BIT 

NAME:  CAD/BIT  •  Computer  Aided  DeslQn  For  Built*ln  Test 
YEAR;  1988  (tint  demonetretlon) 

FUNCTION:  A  traneportable,  uaer  friendly,  menu  driven  CAD/CAE  aoftware 
program  that  automatea  muoh  of  the  proceaa  linking  BIT  to  the  functional  dealgn. 
CAD/BIT  conalata  of  the  following  three  major  aeotlona; 

•  The  Tutorial  Phaee:  Any  of  the  CAD/BIT  teohniquea  contained  In  the 
library  oan  be  either  briefly  or  fully  deaorlbed. 

•  The  Baleotlon  Phaae;  Baaed  on  Information  provided  by  the 
dealgner,  the  CAD/BIT  aoftware  will  diaplay  aultable  BIT  teohniquea 
and  rank  them  aooording  to  varloua  Figures  of  Merit. 

•  The  Implementation  Phaae:  After  a  BIT  technique  hai  been 
determined,  It  la  diaplayed  In  an  Implementation  diagram.  The 
dealgner  la  provided  with  aufficlent  information  to  add  BIT  circuitry 
almllar  to  the  way  he  would  add  functional  circuitry.  All  circuitry 
added  apeolfloally  for  BIT  la  totalled  for  additional  Informational 
output. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  Efifi  8UBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  1/N  (QFE) 

DESIGN  ENV;  CAD/BIT  Is  written  In  C,  operates  on  UNIX,  and  usaa  the  IQES 
tranafer  protocol. 

CIRCUIT  DESCRIPTION:  Information  on  the  funotlonal  circuit  block  to  be  teated  Is 
derived  from  reaponees  to  questions  asked  the  dealgner. 

USE  PREREQUISITE:  Knowledge  of  how  the  system  will  be  partitioned  Into 
physical  PCBs  and  what  funotlonal  blocks  of  circuitry  will  reside  on  the  PCB  to 
wNch  BIT  olrouHry  la  to  be  added. 

DEVELOPER:  Grumman  under  oontraot  to  RAOC. 
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COMMENTS:  CAD/BIT,  at  damonatralad,  it  pradominantly  gaarad  for 
PCB/modula  daslgntrs  using  dlacrata.  ofMha*shtlf  componants.  For  thoso 
Implamanting  thoir  PCB/modulo  datign  with  VLSI  ASICs  (full  or  sami’Oustom 
standard  calls,  gats  arrays,  PALt,  silicon  compllad  davloas,  ate.),  its  affactivanass 
tapars  off;  howavar,  tha  tutorials,  BIT  salactlon  logic,  and  Implamantatlon 
Instruction  still  basically  apply.  In  fact,  much  of  CAD/BIT  Is  quite  ralavant  to  tha 
VLSI  dasign  prooass. 

Tha  CAD/BIT  library  contains  both  structurad  and  ad  hoc  BIT  tachnlquas  that 
partain  to  both  digital  and  analog  circuitry.  Tha  tachnlquas  antall  usa  of  both 
hardware  and  software  and  oan  ba  applied  to  both  oonourrant  and  non*oonourrant 
BIT  execution. 

CAD/BIT  supports  tha  maintananoa  philosophy  that  mandates  for  each  PCB  In  tha 
system  to  have  tha  capability  of  tasting  itself  and  ba  able  to  report  a  go/no*go 
signal  after  test.  Much  confidanea  must  ba  placed  In  tha  reliability  of  this  go/no-go 
signal,  particularly  in  military  systems.  Whan  dona  properly  and  reliably,  a  PCB 
self  test  system  dramatloally  Impacts  tha  following: 

•  Fault  isolation  time/  system  readiness. 

•  Factory*  and  Dapot'laval  system  vartftoatlon  tasting  complexity. 

•  Organizational  maintananoa  personnel  skill  level. 

REFERENCES; 

1 .  Lt  T.W,  Oxford,  'Computer  Aided  Design  For  BulIMn  Test  (CAD6IT),” 
ATE  &  instrumentation  Conference,  dune  1987. 

2.  Air  Force  Point  of  Contact 
RAOC/RBES 

Qrlffisa  AFB,  NY  13441-5700 
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3.1.4  CADAT 
NAME:  CADAT  6 
YEAR: 

FUNCTION:  CADAT  6  It  oompoted  of  th«  following  rolattd  tools  opsrating  from  a 
single  user  data  base: 

-  LOGIC  SIMULATION;  to  vtrHy  the  baas  functionality  of  the  dasigner'a 
oonoapt  and  detailed  logic  design. 

•  PERFORMANCE  SIMULATION;  to  analyze  the  oiroult  propagation 
oharaoterlatioa  of  the  design  under  worst  case  timing  conditions. 

•  FAULT  SIMULATION;  to  evaluate  the  effeotiveness  of  test  vsotors 
developed  by  the  designer  or  the  test  department  for  manufacturing 
test  of  the  final  design. 

The  CADAT  Fault  Simulation  option  utilizes  a  functional  Concurrent  Fault 
Simulation  algorithm  to  analyze  the  Impact  of  potential  manufacturing  errors  and 
oiroult  failures.  The  algorithm  optimizes  simulation  throughput  for  all  levels  of 
device  modeling,  from  switch  level  to  hardware. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  YLSl  PCS  8UBSY3  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEKWAL  ESB  PRDOTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 
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DESIGN  ENV:  CADAT  6  will  run  on  tho  following  hardwaro  platforms; 

Apollo/AEQISwIth  AUX 

IBM  PC-AT/PC-D08  (Porsonal  Cadat) 

IBM  MVS 

IBM  VM/CMS 

SUN  MIoroayatama  UNIX 

VAX  ULTRIX 

VAX  VMS 

LANA  (Local  Araa  Network  Acoalaration)  Is  also  avallabla. 

CIRCUIT  DESCRIPTION:  Behavioral  Design  Language  (BDL) 

USE  PREREQUISITE:  Behavioral  description  or  a  circuit  netllst  must  be  Input. 
DEVELOPER;  HHB  Systems 

COMMENTS;  The  following  are  CADAT  related  HHB  produota; 

Personal  CADAT  An  Integrated  logic,  timing  and  fault  simulator  for 

use  on  the  IBM  Personal  Computer. 

CATS  Modeler  Enables  designers  to  Incorporate  physical  model  of 

LSI  and  VLSI  chips  Into  logic,  timing  and  fault 
simulations. 

CATS  Accelerator  Hlgh<speed  simulation  on  a  special  purpose  system 

(300  times  faster  than  a  VAX/780). 

THESEUS  Automated  test  generation  for  ICs; 

oomblnatlonaLsequential,  and  scan  path  circuits. 

Extensive  Device  Library  Software  models  of  SSt/MSI  devices,  LSI  Logic 

goto  arrays,  and  Standard  Microsystems'  standard 
cells.  Hardware  models  of  LSI/VLSI  devices  from 
Intel,  Motorola,  Tl,  Zllog,  and  others. 

In  order  to  maximize  the  utilization  of  relevant  test  data  created  during  the  design 
process,  post  processor  links  to  a  growing  range  of  test  systsms  have  been 
developed.  These  range  from  go/no-go  links  with  1C  test  systems,  such  as  Sentry, 
to  complete  diagnostic  data  base  links  with  leading  high  performance  PCB  test 
systems,  such  as  titose  from  Faotron,  Teradyne  and  Computer  Automation. 
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In  k««ping  with  Industry  trends  toward  user  Integration  and  open  syatem 
architecture,  CADAT  accepts  network  Information  developed  on  any  system  having 
an  EDIP  output  format.  Implementation  of  this  industry  standard  Is  further 
enhanced  In  CADAT  6  by  the  addition  of  a  totally  new  data  base  access  package 
known  as  the  CADAT  Systems  Interface  (C8I), 

CSI  allows  the  user  to  access  all  aspsets  of  the  simulation  data  base  such  as 
stimulus  responses,  and  topology  Information,  with  a  aeries  of  high-level  call 
functions.  These  can  be  used  to  derive  output  data  from  CADAT  in  any  desired 
format  Incorporating  any  parts  of  the  Internal  data  base  developed  during 
simulation. 

REFERENCES; 

HHB  Systems 

Attn;  Mr.  Kenneth  LIpston 

1000  WycKoff  Ave. 

Mahwah.N.J.  07430 
(201)  846-8000 
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3.1.5  DAISY 
NAME:  DAISY 
YEAR: 

FUNCTION:  Daisy  Logician  Workstation  Is  Intel  80286  based  and  supports  DTA 
along  with  QATEMASTER,  CHIPMASTER,  BOARDMASTER,  and 
MEQAQATEMASTER.  Validation  by  Daisy  Logic  Simulator  ensures  the  design  Is 
ready  for  DTA.  Daisy's  recommended  design  sequence  Is:  DANCE  •  DRINK  -  SIFT 
-  SOM  ■  DTA. 

Refer  to  Daisy  Testability  Analyzer  (4.1 .6). 
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3.1.6  1088 

NAME:  1088  >  inttgratod  Diagnostic  Support  System 
YEAR;  1989 

FUNCTION:  The  Navy's  Integrated  Diagnostic  Support  System  Is  developing  an 
Innovative  approach  to  diagnostics  via  the  development  of  an  Integrated  set  of 
software  tools.  All  of  those  tools  function  within  the  context  of  a  standard  common 
diagnostic  data  base  (CDDB).  The  CDDB  Is  a  predefined  set  of  logistic  and 
technical  data  elements  derived  from  weapon  system  design  and  logistics  data. 
Preprocessors  are  required  to  Input  CAE  and  LSA  data  Into  the  CDDB.  Tools 
currently  under  development  are; 

•  Weapon  System  Testability  Analyzer  (WSTA) 

-  Adaptive  Diagnoatio  Subsystem  (ADS) 

•  Adaptive  Diagnostic  Authoring  Tool  (ADA) 

•  Feedback  Analyzer  (FA) 

•  Technical  Information  and  Training  Authoring  (TIATA)  Tool 
A  brief  description  of  each  software  tool  la  provided  below. 

WEAPON  SYSTEM  TESTABILITY  ANALYZER  (WSTA) 

The  WSTA  requires  as  Inputs  unit  under  test  digital  or  analog  topology 
and  logistic  support  analysis  (LSA)  data.  WSTA  then  generates  a  test  strategy 
which  Is  very  near  optimal  In  terms  of  minimizing  average  teat  times  or  test  costs. 
A  primary  function  of  WSTA  is  to  provide  static  (topological)  testability  figures  of 
merit,  such  as  average  Inherent  ambiguity  group  size  and  feedback  loop 
characterlstlca.  WSTA  alao  provides  dynwnlo  (test  strategy  based)  figures  of  merit, 
such  as  mean  or  maximum  time  to  fault  Isolate.  WSTA  providee  guidance  to  the 
designer  on  the  optimal  placement  of  teat  points  based  on  the  fault  Isolation  data 
each  test  point  can  provide.  WSTA  utilizes  a  system  dependency  model  and  the 
time-efficient  sequencer  of  tests  (TEST)  algorithm  to  generate  an  optimal  test 
strategy.  WSTA  Is  currently  In  BETA  site  testing  and  la  scheduled  for  distribution  to 
Interested  government  and  contractor  organizations  during  1989. 

ADAPTIVE  DIAGNOSTIC  SUBSYSTEM  (ADS) 

The  ADS  Is  an  Intelligent  troubleshooting  aid  which  provides  a 
recommended  "next-best”  test  or  a  recommended  repair  action.  The  ADS  contains 
logic  to  utilize  the  diagnostic  resources  (e.g.,  BIT,  augmented  BIT,  guided  manual 
test,  technician  Inputs,  etc.)  and  diagnostic  reasoners  (e.g.,  optimal  WSTA 
strategy,  original  dependency  data,  production  rules,  etc.)  which  will  have  the  most 
likelihood  of  success  based  on  the  diagnostic  session  results  up  to  that  point.  The 
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ADS  applltt  Inortailngly  sophiatloatad  "lava!  of  Intalllganoa*  to  tha  prublam,  but 
only  a»  naadad.  It  ramambars  Its  succassas  and  failuras  and  automatically  adapts 
Its  tast  stratagy  to  changing  fallura  ratas  and  tast  anvironmants.  Tha  ADS  may  ba 
utlllzad  as  a  diagnostic  software  shall  for  both  ambaddad  and  off>llna  tast  program 
sat  (TPS)  applloatlona. 

ADAPTIVE  DIAGNOSTIC  AUTHORING  (ADA) 

Tha  ADA  validates  tha  modal  and  optimal  stratagy  generated  by  WSTA; 
organizes  weapon  syatam^spaoiflo  data  from  tha  IDSS  data  base;  adds  production 
rules  to  update  existing  stratagy,  based  on  tha  analysis  of  on>golng  weapon 
system  performance;  and  authors  tha  diagnostic  program,  which  Is  than  provided 
as  Input  to  tha  ADS. 

FEEDBACK  ANALYZER  (FA) 

Tha  FA  Is  a  software  aid  that  gathers  global  feedback  fallura  data  (a.g., 
type  of  fallura,  fault  symptoms,  environmental  conditions,  etc.)  and  performs  an 
analysis  to  determine  tha  significance  of  tha  failure  as  It  relates  to  anhanoamants  of 
fault  detection  and  Isolation  strategy.  Tha  ADA  utiiizae  tha  output  of  tha  FA  to  aid 
tha  user  In  authoring  new  production  rules  for  addition  to  tha  existing  diagnostic 
procedures. 

TECHNICAL  INFORMATION  AND  TRAINING  AUTHORING  TOOL  (TIATA) 

Tha  TIATA  Is  a  software  aid  which  uses  waapon«soaolflc  data  from  an 
IDSS  data  base  to  generate  maintenance  procedures,  tutorials,  circuit  sohamatlos, 
or  parts  breakdown  diagrams  needed  by  tha  maintenance  taohnlolan  as  part  of  tha 
diagnostic  process.  This  tool  also  has  tha  oapablllty  to  generate  tailored  training 
sessions,  enhance  maintenance  reporting,  and  facilitate  user  Interaotlon  with  the 
IDSS  data  bases. 

CAPACITY:  hVA 

CPI  TIME:  N/A 

APPLICATION:  VLSI  P£fi  SUBSYS  SYSTEMS 

ACQUISITION  PHASE:  CONCEPT  DEMA^AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?  Y/N  (GFE) 

DESIGN  ENV:  To  properly  execute  the  Berkeley  CAE  preprocessor,  the  LSA 
preprocessor  and  Weapon  System  Testability  Analyzer  Program  requires  either  a 
Sun  3/160  computer,  with  UNIX  42  (Berkeley  version)  operating  system,  or  a 
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Digital  EquIpmant  Corporation  MIoro  Vax  II,  with  a  Virtual  Memory  System.  A 
minimum  of  four  Mbytes  of  main  memory  is  required,  with  16  Mbytes  of  virtual 
memory  for  the  Sun,  and  four  Mbytes  main/16  Mbytes  virtual  memory  for  the  MIoro 
Vax  II. 


Additional  Information  oonoerning  hardware  platform  requirements 
needed  to  properly  execute  the  remainder  of  the  IDSS  tool  set  will  be  provided 
upon  product  release  of  each  Individual  tool. 

CIRCUIT  DESCRIPTION:  All  teohnioai  Information.  CAD/CAE  data,  and  ILS  data 
are  processed  Into  standard  CODS  format  and  are  aooesalble  to  taoh  of  the  four 
IDSS  design  tools. 

USE  PREREQUISITE:  CDDB  data  elements  required  as  data  Inputs  for  each 
particular  tool  must  be  provided. 

DEVELOPER:  Harris  Corporation  under  contract  from  the  US  Navy. 

COMMENTS:  A  key  design  concept  of  IDSS  Is  the  delivery  of  complete  support 
over  the  full  life  cycle  of  the  weapon  system. 

REFERENCES: 

1.  Dr.  Bruce  J.  Rosenburg,  "The  Navy  Integrated  Diagnostic  Support 
System  •  System  Overview,  Architecture  and  Interfaces,”  IEEE 
AUTOTESTCON  1087. 

2.  Navy  Point  of  Contact 
NAVSEA  -  Code  CEL-DS 
Washington,  DC  20362<6101 
(202)  e92-2036/2036 
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3.1.7  LASAR  VERSION  9 
NAME:  LASAR  VERSION  6 
YEAR:  1982,  origin  1978 

FUNCTION:  It  provides  a  CAD  simulation  system  for  design  verification  and  test 
program  generation  Incorporating  the  testability  subprograms  called  Judge  & 
Prosecutor.  Refer  to  Section  3.3.2. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  ^  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N  (PRTY) 

DESIGN  ENV:  VAX;  VALID  S320;  TERADYNE  DATA  SERVER;  IBM  PC  AT;  also 
supports  design  entry. 

CIRCUIT  DESCRIPTION:  TML  -  an  optional  register  transfer  language. 

USE  PREREQUISITE:  LASAR  Version  6  netllst  format;  translators  available  to 
convert  leading  CAD/CAE  circuit  data  bases. 

DEVELOPER:  Teradyne 

COMMENTS:  When  LASAR  Is  used  for  both  design  verification  and  test  program 
generation,  test  programming  time  shrinks  by  50%  or  more.  There’s  no  need  to 
recreate  the  circuit  model  or  stimulus  vectors.  Only  one  set  of  models  must  be 
maintained.  Test  development  can  begin  Immediately  after  design,  in  parallel  with 
prototype  production  and  verification. 

LASAR  VERSION  6  supports  the  following  modeling  features: 

There  Is  a  library  of  over  4,000  SSI,  MSI,  and  LSI  device  models  and  gate  array 
macros,  including  m'^  nufacturer's  timing.  Input  loading  delay  factors,  and  current 
drive  strength  specifications. 

Behavioral  modeling  language. 
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Hardware  modeling  with  behavioral  software  enhancement  for  repeatable 
simulation,  min/max  timing  analysis,  and  fault  simulation. 

RAMGEN,  ROMQEN,  PLAGEN,  PLAGEN  programs  for  rapid  structural  modeling 
of  repetitive  logic  devices. 

Tester  characteristics  are  taken  Into  account  In  parallel  with  circuit  test  generation 
and  are,  therefore,  easily  Integrated  with  ATE  hardware,  minimizing  the  time 
required  to  debug  testa. 

Post'proceasors  translate  stimulus  and  response  data  Into  the  symbolic  language 
of  the  target  teat  system  for  go/no*go  test  and  fault  diagnosis. 


REFERENCES: 

1,  Teradyne,  Inc. 

Attn:  Fred  Grant 
321  Harrison  Ave. 

Boston,  Ma.  02118 
017-482-2700 

2.  Mary  Wasllowlkl,  "Simulation  Modeling  of  the  Test  System 
Environment  to  Speed  Board-Test  Program  Debugging  and  Tester 
Integration,"  International  Test  Conference  1987 
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3.1.8  MENTOR  GRAPHICS 
NAME:  MENTOR  GRAPHICS 
YEAR: 

FUNCTION:  Mentor  Qraphlos  provides  a  design  system  Integrated  with  software 
support  tools  that  relate  to  design  of  function  as  well  as  to  design  of  the  diagnostic 
capabilities  of  that  function.  In  particular.  It  provides  a  deterministic  fault  simulator. 

Refer  to  the  Tools  For  ATQ/Fault  Simulation  section. 

APPLICATION:  N^LSl  £Si  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^^/N  (PRTY) 

DESIGN  ENV;  Mentor  Graphics  engineering  workstations 

CIRCUIT  DESCRIPTION:  See  above  for  all  Mentor  Graphics  model  types 

USE  PREREQUISITE:  Schematic  must  be  captured  using  a  Mentor  Qraphlos 
model  type;  use  with  QUICKSIM. 

DEVELOPER:  Mentor  Graphics  Corporation 

COMMENTS: 

REFERENCES: 

Mentor  Graphics  Corporation  Frank  BInnendyk 

8500  S.W.  Creekside  Place  Product  Manager 

Beaverton,  Oregon  97005*7191  Design  and  Analysis  DIv 

(503)  626*7000 


C*54 


DESIGN  ALTTOMATION  TOOLS 

3.1.0  MIDAS 


APPENDIX  C 


NAME:  MIDAS  •  Modular  Intagratad  Daslgn  Automation  System 
YEAR:  1085  (Periodic  updates) 

FUNCTION:  Pull  simulation  support  for  selected  semiconductor  technologies 
(CMOS  gate  arrays,  TTL  MSI  logic,  etc.),  from  gate  level  simulation  to  subsystem 
and  system  scale.  MIDAS  supporta  logic,  timing  and  fault  simulation. 

In  1087  N.2  was  added  for  architectural  and  RTL  level  simulation.  This  tool  has  a 
graphic  interface  on  Apollo  workstation.  Tl?ls  Interface  Is  a  set  of  block  symbols, 
which  can  be  used  to  draw  the  RTL  level  diagrams.  The  netllst  Is  produced 
automatically  on  the  workstation. 

Using  ths  MIDAS  simulation  tools  with  N.2  as  a  front  end,  the  simulation  process  Is 
as  follows: 


•  Define  arohiteoturo  and  timing  constraints  using  N.2 

•  Define  subsystems  using  N.2 

•  Enable  software  simulator  using  the  subsystem  level  models 

•  Break  subsystems  Into  Individual  chips 

•  Verify  chip  designs  using  logic,  timing  and  fault  simulators  (MIDAS) 

•  Verify  chips  In  subsystem  environment  (MIDAS) 

•  Verify  subsystem  In  system  environment  (MIDAS) 

CAPACITY:  Targeted  for  one  chip  through  large  designa. 

CPU  TIME:  Depends  on  system  size  and  simulation  methods  used. 

APPLICATION:  yLSl  SSS.  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ■  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N  (PRTY) 

DESIGN  ENV:  CYBER  mainframes  with  Apollo  workstation  front  end 

CIRCUIT  DESCRIPTION:  MIDAS  Logic  Interconnect  Language  netllst.  (VHDL  In 
the  future.) 

USE  PREREQUISITE:  Ample  definition  of  a  function  to  be  designed  and 
Implemented  with  gate  arrays. 
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DEVELOPER:  MIDAS  •  Control  Data  Corporation 
N.2  •  ENDOT,  Inc. 

COMMENTS:  STAFAN  Is  a  part  of  the  MIDAS  toolsat.  Saa  Ref[1]  and  refarto  tha 
saction:  Tools  That  Aid  In  Fault  Simulation  Tasks. 

A  significant  faaturs  of  tha  consultant  sarvloas  offarad  by  MIDAS  parsonnal,  Is  that 
thay  w'li  offar  Instruction  on  how  to  Implamant  BIST  (BulIMn  Saif  Tast)  Into  tha 
functional  dasign.  Control  Data  has  a  numbar  of  implamantatlons  for  BIST,  undar 
tha  namas  of  OCMS  (for  6000-gata  arrays).  BEST  (for  20,000‘gata  arrays)  and 
VISTA  (for  standard  call). 

Thasa  built-in  salt  tast  circuits  support  chip  as  wall  as  systam  laval-tast.  Saa 
Rafs(2]&[3]. 


REFERENCES; 

1.  Jain,  S.K,,  Agrawal,  V.  0.,  "STAFAN:  An  Altarnativa  to  Fault 
Simulation,  Dasign  Automation  Confaranoa,  1084 

2.  Ron  Laka,  *A  Fast  20K  Qata  Array  With  On-Chip  Tast  Systam,”  VLSI 
Systams  Dasign  (magazina),  Juna  1986. 

3.  David  R.  Rasnlok,  "Tastablllty  and  Maintainability  with  a  Naw  6K  Qata 
Array,”  VLSI  Dasign  (magazina)  Mar/April  1983. 

4.  Control  Data  Corporation 

ADAM  Markating,  MInnaapolis,  MN 
Attn:  Robart  Biggs  HQM274 
(612)  863-3117. 
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NAME;  MM8T  •  MImola  Module  For  Self  Test 

MIMOLA  •  Machine  Independent  Microprogramming  Language 

YEAR:  1979 

FUNCTION: 

•  Automatic  aelf  test  program  generation  which  can  be  Implemented  In 
micro  or  machine  code. 

•  Optimizes  TY  and  coat  tradeoffs. 

>  Reports  poor  CY  and  OY. 

CAPACITY:  Circuit  nodes  on  the  MIMOLA  design  level  normally  are  register* 
transfer  modules,  that  is  complete  ALUs,  RAM.  ROM,  registers,  multiplexers, 
buses,  etc.  Only  In  special  oases  modules  are  sln^ple  logic  gates.  The  current 
Implementation  allows  several  hundred  of  such  circuit  nodes.  This  number  could 
be  Increased,  but  up  to  now  even  in  the  moat  complex  applications  It  has  never 
been  a  limitation. 

CPU  TIME:  (Example)  3,000  fault  free  instructions  took  20  min. 

APPLICATION:  M  E2fi  SUB8Y8  8Y8TEM 

ACQUI8mON  PHA8E:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 

0E8IQN  ENV:  MIMOLA  Is  written  In  pure  standard  Pascal  and  runs  on  any 
machine  and  operating  system  that  has  a  Pascal  compiler  and  at  least  one 
megabyte  of  unsegmented  main  memory.  Among  others,  applications  are  running 
on  VAX  (VM8.  UNIX),  Sun,  and  Apollo  workstations. 

CIRCUIT  DESCRIPTION:  CHDL;  part  of  MIMOLA 

USE  PREREQUISITE:  Functional  model  of  the  target  circuit. 

DEVELOPER:  Institut  fur  Informatik  u.  Prakt.  Math. 

COMMENTS:  Most  unique  about  MSST  is  that  It  allows  automatic  generation  of 
self  test  programs  In  binary  code  for  complete  processor  systems,  including  paths 
of  high  sequential  depth.  Such  self  test  programs  tor  system*level  test  are  usually 
still  written  by  hsnd  and  are  tedious,  requiring  highly  skilled  specialists. 
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Th«  MIMOLA  Dtsign  Sytttm  It  •  product  funded  by  Uit  German  govarnmant.  It  la 
ganarally  avallabla  but  a  contribution  to  tha  davalopmant  coat  la  axpaotad  If  It  la  to 
ba  uaad  oommarclally. 

REFERENCES: 

•  Krugar,  Q.,  "Automatic  Qanaration  of  Saif  Taat  Programa  -  A  Naw 
Faatura  of  tha  MIMOLA  Oailgn  Syatam,"  IEEE  DAC  1066. 

•  For  a  trial  varaion  contact; 

Dr,  Patar  Marwadal 

Inatltut  fur  Informatik  u.  Prakt.  Math. 

Univaraltat  Klal 
Olihauaanatr.  40<eo 
D-2300  Klal  1 
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NAME;  8ILVAfl-U8CO 
YEAR;  1081 

FUNCTION;  Th«  8llv«r«Lltoo  CAE  Softwtrt  Envtronm«nt  It  an  all  Inoluilva  daaign 
aid,  aaalating  In  almoat  avary  daitgn  itaga  from  achamatic  oaptura  to  tha  final  atap 
bafora  manufacturing.  Tha  aoftwara  anvironmant  IriOludaa: 

•  808  (Sohamatio  Daaign  Syatam):  8D8  oraataa  or  "oapturaa"  tha 
daaign  data  baaa,  whioh  atoraa  tha  baalo  loglo  Information  uaad 
throughout  tha  Intagratad  Daaign  EnvIronmant  uaing  a  multi-window 
taehniqua  whioh  allowa  tha  daaignar  to  vlaw  varloua  aohamatloa  and 
to  work  on  aavaral  lavala  of  daaign  almultanaoualy. 

•  HELIX:  A  hlararohloal,  top-down,  bahavioral  logic  almulator,  HELIX 
allowa  daaignara  to  prova  tha  prinotpla  of  thair  oonoaptual  daaign  at 
Ita  block  diagram  ataga.  Whan  and  If  aatiaflad.  tha  datalla  oontinua  to 
ba  workad  out  at  tha  raglatar  laval  and  than  tha  gata  laval. 

I 

•  ANDI  (Analog-Digital  Simulation);  Providaa  functional  tima  domain 
Emulation  of  mixad  analog/dlgltal  aamplad  data  ayatama.  ANOI'a 
analog  primittvaa  ara: 

•M08  tranaiator  awitchaa 
•Bipolar  tranalatora 
-DIodaa 

•Indapandant  and  oontrollad  voHaga  and  currant  aouroaa 

•Induotora 

•Raaiatora 

•Capacltora 

-  In  addition  to  tha  abova  analog  prlmltlvaa,  ANDI  aarvloaa  common 
digital  prlmltlvaa  auoh  aa  gataa,  ROM  &  RAM,  PLAa,  fllp-flopa,  ate.,  aa 
wall  aa  A/D  and  D/A  oonvartara. 

-  8WAP;  Providaa  tIma  and  fraquanoy  domain  almulatlon  of  awltchad- 
capacltora  natworka.  Non-llnaar  tranaiator  modala  ara  aimpllflad  to 

‘  M08  awitchaa.  Fraquancy  domain  oaloulatlona  ara  mada  dlractly  In 
tha  fraquancy  domain,  with  no  naad  to  ba  followed  by  a  Fact  Fourlar 
Tranaform  (FFT).  SWAP  la  oonduolva  to  a  broad  ranga  of  analyaaa 
Including  aanaltivlty.  diatortlon,  band-acan,  and  nolaa  analyaaa. 
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•  For  m«th«matloal  rtaaona  all  analyaaa,  axoapt  distortion  analysis,  ara 
llmitad  to  switohad-capaoltor  natworks  with  only  llnsar  oomponants. 
For  afflolsney  saka,  all  hlgh*laval  analysas,  Including  dlstoiilon 
analysis,  raquira  that  tha  oiroult  doas  not  hava  any  tima  constants 
oausad  by  rssistors  or  Inductors. 


CAPACITY: 

CPU  TIME: 

APPLICATION:  )m  £&fi  8UB8YS  SY.SIfiM 

ACQUISITION  PHASE:  CONCEPT  DEWVAL  Efifi  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  (PRTY) 

DESIGN  ENV:  In  addition  to  tha  abova  utllltlas,  8livar*Llsoo  also  providas  a  printad 
oiroult  board  dasign  systam  utility  as  wall  as  tha  following  numaroui  utllltlas  In  tha 
1C  davalopmant  raalm: 

ICOavalQDmant 

PRINCB88:  A  full  ouatom  physical  dasign  systam. 

QARD8:  A  gata  array  daaign  systam. 

CAL-MP:  A  standard  call  daaign  systam. 

UDRC:  A  univarsal  dasign  rula  ohackar. 

Blaotrleal  Varlfloatlon:  A  sat  of  varifloatlon  utllltlas  Including  six 
ohaoking  utllHias,  a  oiroult  axtraotor,  and  a  SPICE  natllst  ganarator. 

YIELD:  A  gaomatrio  ylald  analyzar. 
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Milk  D>f  Prtpamtlon 

UMDP:  A  univtrtal  maik  data  praparatlon  utility. 

Sllvar>Lltoo  CAE  produota  oparata  on  Apollo,  IBM,  Sun,  and  VAX  computing 
ayatama,  howavar,  not  avary  utility  runa  on  aach  of  thaaa  four  platforma. 

CIRCUIT  DESCRIPTION:  HELIX  Hardware  Daaorlptlon  Language  (HHDL) 
providaa  the  ability  to  write  behavior  for  oomponanta,  daaorlba  parta  with  oomplax 
behavior,  and  modal  oonourrant  daaign  funotlona. 

USE  PREREQUISITE:  Sea  808  above.  808  tranalataa  daaign  data  Into  natllat 
format,  or  Ha  funotlonal  equivalent.  Sea  oommanta  for  varloua  Intarfaoaa  avallabla. 

DEVELOPER:  SHvar-Uaoo 

COMMENTS:  The  8llvar«Llaoo  CAE  aoftwara  environment  la  Idaal  for  Syatam 
Intagratad  Taat  (SIT)  daaignara  In  that  they  oan  almulata  a  oonoaptuailzad  SIT  and 
work  out  many  of  the  typloai  problama  (l.a.,  maintananoa  bua  Intarfaolng,  ETE 
oompatiblllty,  BIT  loglo  flow,  taat  aaquanoing,  ato.)  and  than  allocate  that  portion  of 
the  overall  aohama  to  the  embedded  BIT  daaignar  at  the  PCB  iavai,  who  oan 
almilarly  paaa  on  hla  aohama  to  the  VLSI  people  who  In  wm  oan  play  their  own  BIT 
gamaa.  Furthermore,  Ita  oapabllltlaa  of  handling  both  dIgHal  and  analog  oiroultry, 
aa  wall  aa  aynohronoua  and  aaynohronoua  daaigna,  make  It  even  more  attractive. 

Optional  plotting  paokagaa  are  avallabla  for  generating  documentation  on  widely 
uaed  plottera. 

An  optional  aoftwara  paokage,  Engineering  Aooaaa  Routine  Set  (EARS),  providaa 
direot  aooaaa  to  the  oentral  data  baae  promoting  the  ability  to  write  Intarfaoaa  to 
proprietary  aoftwara.  A  report*generatlen  utility  oan  be  made  for  example. 

Optional  intarfaoea  aupport  the  following  aimulatora  and  ayatama: 

• TEQAS 

•  SPICE 

-  8ALOQ8 

•  LOQCAP 
•ILOQS 

'  SCl'CARDS  ayatem 

•  HILO 

-  SUPER-COMPACT 

•  Applleon  ayatem 

•  CBDS  ayatem 

•  REDAC-CADET  ayatem. 
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Uitrt  mutt  purchatt  Fault  Simulators,  ATPQs,  and/or  Tastablllty  Analyzart  from 
outside  sources  at  they  are  not  provided  by  Slivar-Litco. 

Profile  (tee  Prediction  Tools)  uses  the  ANDI  simulator  during  Its  process. 

REFERENCES: 

Sllvar*Llsco 

Corporate  Headquarters 
1080  Marsh  Road 
MenloPark,CA  04026 
(416)324-0700 
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3.1.12  8PICE/P8PICE 
NAME:  8PICE/P8PICB 
YEAR;  1984  (PSPICE) 

FUNCTION:  Although  SPICE  dots  not  provido  dttign  aid  spaolflo  to  tha  task  of 
Intagrating  diagnostic  oapabllltias  Into  a  functional  design,  It  Is  ona  of  tha  faw 
software  tools  available  for  analog  design  simulation.  Soft  simulation  before  a  hard 
prototype  Is  a  prime  advantage  of  being  able  to  assess  and  predict  the  merits  of  a 
function's  diagnostics. 

There  are  various  versions  available  of  the  analog  simulator  known  as  SPICE. 
SPICE  2  was  developed  at  the  University  of  California  at  Berkeley  In  the  late  60's 
and  early  70'a.  PSPICE  originated  from  SPICE  2  and  Is  the  chosen  version  for  this 
document  due  to  Its  popularity.  This  fact  sheet  will  concern  facts  about  PSPICE. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  YLSl  £SB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  fSB  PRDCTN  OPLYMNT 

PUBLIC  DOMAIN?:  >t/N  (PRTY) 

DESIQN  ENV:  IBM  PC  and  PS2  compatibles  (DOS)  (Aug  1  OS/2),  Macintosh  II, 
Sun  3/4,  VAX  (Micro,  supemnlnl,  and  mainframe). 

CIRCUIT  DESCRIPTION:  Compatible  with  a  variety  of  commercially  available 
schematic  capture  programs. 

USE  PREREQUISITE:  Circuit  devices  must  be  modeled  using  either  the  model 
library  of  parts  Included  or  developed  from  data  sheet  Information  using  "Parts,"  an 
optional  utility. 

DEVELOPER:  PSPICE  Is  developed  by  MicroSIm  Corp. 

COMMENTS:  PSPICE  performs  the  following  types  of  analyses; 

•  DC,  or  bias  point,  voltages  and  currents  of  the  circuit. 

-  AC,  or  frequency,  response  of  the  circuit. 

-  Noise  behavior  of  the  circuit  over  frequency. 
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-  Oavlea  Equations:  Usad  to  ohanga  the  aquations  which  translate 
modal  parameter  values  and  terminal  voltages  Into  the  device's 
currents  and  capaoHances. 

•  Probe:  Punotlons  as  a  software  osolllosoope  with  the  capability  to 
produce  a  hardcopy  printout. 

•  Parte:  Seml>automates  the  process  of  creating  model  libraries. 

•  Monte  Carle  Analysla:  After  Inputting  various  component  tolsrances, 
PSPICE  analyses  are  performed  using  random  values  that  are 
somewhere  In  the  range  of  tolerance. 

I 

>  Digital  PIlea:  Allows  one  to  run  a  digital  simulator  and  use  the  results 
as  Input  to  PSPICE  or  vice  verse. 

It  must  be  emphasized  that  PSPICE  Is  not  marketed  as  a  design  aid  peculiar  to  the 
Inclusion  of  the  TESTABILITY/DIAQNOSTIC  oapabllity.  However,  one  must 
remember  that  much  of  analog  BIT  design  Is  accomplished  quite  successfully  with 
the  following  ad  hoc  techniques;  peak  detector  or  window  comparator,  wraparound, 
substitution  of  a  known  value,  etc.  There  is  IHtie  guidance  required  to  describe  how 
to  Implement  these  techniques,  however,  simulators  such  as  PSPICE  enable  one 
to  optimize  the  design  before  H  Is  breadboarded. 

Furthermore,  although  much  more  tedious  than  using  a  fault  simulator  of  the  digital 
world,  the  Device  Equations  option  Is  useful  in  determining  If  BIT  will  detect  a 
component  failure.  The  Probe  option  Is  handy  for  documenting  troubleshooting 
manuals.  Considering  that  BIT  data  processing  is  almost  always  done  digitally,  the 
Digital  Flies  option  should  prove  worthwhile. 

REFERENCES; 

MIoroSIm  Corporation 
Attn;  Michael  Taggart 
20  Fairbanks 
Irvine,  CA  02718 

(714)  770  •  3022;  (800)  826  -  8603 
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3.2  DMign  RuIm  and  Practloaa 

Tools  that  aid  In  Incorporating  dasign  rulas  and  practicas  Into  a 
diagnostic  capability  that  are  llstad  In  this  saotlon  all  hava  tha  following  faaturas  In 
common: 

•  Thay  ara  usaful  during  mora  than  ona  acquisition  phasa  and,  with  tha 
axcaptlon  of  TDES,  app  to  mora  than  ona  laval  of  Intagratlon. 

•  Thay  apply  to  a  variety  of  hardware  tachnologlas,  Including  analog 
and  digital  circuitry,  [TDES  applies  only  to  digital.] 

•  Thay  ara  all  varsatlla  and  capable  of  many  dasign  assist  functions. 
Those  functions  relative  to  this  document  being:  asauring  standard 
dasign  for  tastabillty  practices,  deploying  rulas  that  Implement  a 
diagnostic  capability,  and  standardizing  diagnostic  data  and  taster 
Information  transport. 

A  summary  description  of  tools  that  aid  In  Incorporating  design  rules  and 
practices  Into  a  diagnostic  system  Is  provided  in  the  following  Table: 
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ACRONYM 

APPUCATION 

COMM»IT8 

ID8S*AD8 

SUBSYSTEM/ 

SYSTEM 

SELECTS  a  INTERPRETS 

TESTS  FOR  PD  A  FI 

MAY  BE  APPLIED  TO 

MANY  DIFFERENT 

CLASSES  OP  SYSTEMS 
INOLUDINQ! 

-  ANALOO  ANtVOR  DIOITAL 
■  MECHANICAL 
•  HYDRAULIC,  ETC. 

TOES 

VLSI 

PROVIDES  SYSTEMATIC 
DIQITALOFT 

METHOOOLOay 

TDES  IS  AN  EXPERT, 
KNOVR.BDQE*BABEO  SYSTEM 
THAT  ISA  PART  OF 

ADVANCED  DESIQN 
AUTOMATION  (ADAM) 

SYSTEM  OP  TOOLS 

TEA- 

PCB/SUBSY8TEM 

SYSTEM 

DPraUIDANOSiBrTHW 
RBOOMMENDATtONSi  BIT 
HWCOBTABBBBSMINT; 
BirHWPUOSMENT 
RECOMMENDATIONS 

USED  IN  CONJUNCTION 

WITH  ADAS;  DEVELOPED 
VERSION  OP  NOT  MUCH 

UBBi  ENHANCED  TEA  IS 

YH  TO  BE  DEVELOPED 

Tisas 

VLSI 

PROVIDES  A  OAPABILiry 
FORINTIRDEPARTMENT 
ACCESS  INTO  ONE.  TEST 
RELATED,  DEV10E 
INFORMATION  DATA  BASE  . 

PROMOTES  EFFICIENT 
INFORMATION  ACCESS 
DURINOTHE 

TESTABILITY/ 

DIAONOSTIO  DISKIN 
PROCESS 

testability 

CHECKLIST 

PCa/BUBSYSTEM 

PROVIDES  STANDARD 

OESION  FOR 

TESTABILITY  FRAOTICRS 

IN  THE  FORM  OF  A 

CHECKLIST 

QUICK  AND  INEXPENSIVE 
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3.2.1  iOSS-ADS 


NAME;  ID88  •  AD8  •  Adaptive  Olegnoetic  System 
YEAR: 

FUNCTION;  A  Knowledge>baaed,  expert  system  that  assists  In  weapon  system  fault 
detection  and  Isolation,  by  selecting  and  Interpreting  tests.  The  ADS  also  updates 
the  data  after  the  fault  Isolation  session  Is  over.  The  ADS  has  the  following 
attributes: 

•  The  ADS  employs  a  generic  diagnostic  process  capable  of  operating 
upon  a  variety  of  applloatlon*apeolfio  knowledge  bases. 

•  The  ADS  minimizes  on«line  computational  load  and  the  speed  of  fault 
Isciitlon  by  first  utilizing  the  simplest  system  model  and  then  progress, 

teoessary,  to  more  complex  models.  See  the  third  comment  below. 

•  It  maintains  a  data  base  of  fault  histories  whioh  Is  used  to  bias  future 
test  and  repair  recommendations.  This  fault  base  Is  also  used  to  flag 
occurrences  when  system  behavior  Is  Inconsistent  with  the  system 
model. 

CAPACITY: 

CPU  TIME: 

APPLICATION;  VLSI  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE;  CONCEPT  DEMA/AL  FSD  PRDOTN  DPLYMNT 

PUBLIC  DOMAIN?;  ^/N  (QFE) 

DESIGN  ENV; 

CIRCUIT  DESCRIPTION:  N/A 
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•  Logistic  data  Including  component  failure  rates,  test  execution  costs, 
etc. 

•  Various  forms  of  design  and  testability  analysis  data,  as  well  as 
functional  Interdependencies  developed  during  the  design  process. 

•  Knowledge  concerning  the  operational  environment  and  situations 
experienced  during  operation. 

•  Technical  Information  via  a  portable  maintenance  aid  Interface. 

•  BIT  Initiation  and  teat  result  Information. 

•  Fault  history  Information  updated  after  every  fault  Isolation  session. 

DEVELOPER:  Harris  Corporation  under  contract  from  the  US  Navy. 

COMMENTS:  After  reviewing  the  type  of  knowledge  upon  which  the  ADS 
operates,  one  realizes  that  these  applloatlon*speolflc  Knowledge  bases  can  be 
largely  developed  from  the  structured  design  process  promoted  by  the  ID8S  design 
philosophy.  Thus,  the  costs  traditionally  associated  with  the  development  of 
Knowledge  bases  required  for  expert  systems  are  greatly  minimized. 

The  generic  nature  of  the  ADS  enables  It  to  be  applied  to  many  different  classes  of 
systems,  including  digital  and/or  analog  avionics,  mechanical,  hydraulic,  and  many 
hybrid  type  systems, 

The  ADS  pre-computed  test  tree  is  built  using  the  Tlme-Efflclent  Sequencer  of 
Tests  (TEST).  If  this  proves  to  be  Inadequate,  ADS  will  deploy  logic  modeling.  If 
this  also  proves  to  be  Inadequate,  ADS  will  rely  on  local  cause  and  effect  rules, 
Ref(2]. 

This  tool  has  been  categorized  under  the  subheading  "Design  Rules  and  Practices" 
because  It  Is  a  rule  based  expert  system  that  is  composed  of  standard  techniques 
and  practices  used  to  diagnose  weapon  system  faults.  One  may  argue  that  ADS  Is 
more  a  troubleshooting  tool  than  a  tool  to  Insure  standard  diagnostic  procedures 
are  used,  however,  it  seemed  appropriate  to  Include  It  in  this  section. 
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REFERENCES: 

1 .  Dr.  Bruce  J.  Rotenburg,  "The  Navy  Integrated  Diagnostic  Support 
System  •  System  Overview,  Architecture  and  Interfaces,"  IEEE 
AUTOTESTCON  1987. 

2.  Magllero,  A.,  R.  Leong,  and  R.  Bethel,  "ADS  •  The  IDSS  Adaptive 
Diagnostic  System,"  IEEE  AUTOTESTCON  1987. 

3.  Navy  Point  of  Contact 
NAVSEA  •  Code  CEL-DS 
Washington,  DC  20362-5101 
(202)  692-2035/2036 
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3^2  TDE8 

NAME:  TDE8  •  TMtabla  DMign  Expert  Systtm 
YEAR:  1085  (prototype) 

FUNCTION:  A  knowltdgd*bMtd  oxpert  tystom  dbdloattd  to  the  following  dttign 
assistant  sarvloas: 

-  Provida  a  syatamatio  DFT  mathodology. 

•  Apply  maasurat  and  attributas  (la.,  fault  oovaraga,  araa  ovarhaad, 
ato.)  to  various  tast  strataglas. 

•  Partition  tha  total  circuit  Into  taatabia  blocks.  Logio  Is  dividsd  Into 
thraa  basic  structures,  combinational  logic,  ragistars,  and  RAMs.  Tha 
basic  structures  ars  further  divided  Into  design  styles.  For  example, 
the  design  styles  of  combinational  logio  are  PLAs,  ROMs,  and 
random  logio. 

-  Match  a  particular  block  of  circuitry  or  karnal  that  has  a  particular 
design  style  with  an  affaotivs  tast  strategy. 

•  Add  circuitry  as  required  to  establish  uniformly  structured  testable 
circuits. 


CAPACITY:  Large  VLSI  circuits;  from  6K  to  100K  transistors 
CPU  TIME:  1  -  2  hours;  not  Including  ATPQ  or  fault  simulation. 

APPLICATION:  ^  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  ^  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/fil 

DESIGN  ENV:  The  prototype  has  been  Implemented  In  Lisp  and  runs  on  a  Sun 
and  DEC-20.  It  Is  part  of  the  Advanced  Design  Automation  system,  ADAM,  see 
Ref  [3]. 

CIRCUIT  DESCRIPTION:  The  design  Is  Input  into  TDES  using  Register  Transfer 
Level  (RTL)  descriptions  (PLAs,  registers,  buses.  RAMs,  ROMs,  stc.). 
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USE  PREREQUISITE:  Dtsign  goals  and  constraints  are  Input  Into  TDES  along 
with  the  RTL  descriptions. 

DEVELOPER:  University  of  Southern  California 

COMMENTS:  TDES  applies  to  digital  circuitry. 

REFERENCES: 

1.  Abadir,  M.S.,  and  M.A.  Breuer,  "A  Knowledge-Baaed  System  for 
Designing  Testable  VLSI  Chips,"  IEEE  Design  and  Test  of 
Computers,  August  1986. 

2.  M.  A.  Breuer,  "A  Methodology  for  the  Design  of  Testable  VLSI  Chips," 
Proo.,  IEEE  Workshop  on  Test  Environments,  pp.  105-114,  Sept. 
17, 18. 1985. 

3.  Abadir,  M.  and  M.  A.  Breuer,  "Test  Schedules  For  VLSI  Circuits," 
IEEE  Trans,  on  Computers,  vol.  o-35,  pp.  381  •  387,  April  1968. 
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3.2.3  TEA 

NAME:  TEA  •  TmI  EngiOMrs  Assistant 
YEAR;  1988  (basic  phasa  prototypa) 

FUNCTION;  TEA  provides  hlgh-laval  system  testability  design  support  In 
conjunction  with  high-level  functional  design  aasistanoe  provided  by  ADAS 
(Architecture  Deeign  and  Assessment  System).  TEA  consists  of  the  following  five 
modules: 

•  Deeign  for  Teeteblllty  Guideline  Checker:  Identifies  violations  of 
OFT  guidelines. 

•  BIT  Herdwere  Recommendation:  Provides  advice  as  to  which  BIT 
method,  deterministic  or  pseudorandom,  Is  most  adequate  for  the 
circuit  at  hand. 

•  BIT  Coat  Aeeeeement  Module:  Predicts  the  general  cost  of 
Implementing  a  particular  BIT  technique  In  terms  of  additional  PCB 
real  estate  and  I/O  ports. 

-  BIT  Placement  Recommendation:  Guides  the  designer  as  to  where 
BIT  components  and  testpolnts  should  be  placed  end  then  calculates 
the  costs  associated  with  such  an  addition. 

•  Teatablllty  Paollltlee  Coat  Aaeessment;  Accounts  for  each 
Incremental  change  Included  for  testability  and  provides  the  total  cost 
of  Implementing  them. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  Efig  SUB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  F5D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/N  (GFE) 

DESIGN  ENV:  TEA  was  developed  to  be  used  with  ADAS  (Architecture  Design 
and  Assessment  System).  See  ADAS  for  design  environment  requirements. 

CIRCUIT  DESCRIPTION:  VHDL 
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— HI—  nil.  ■  . . .  1,11, . . .  — 

USE  PREREQUISITE:  Hlgh*l«v«l  datorlptlon  of  th§  functional  circuitry  that  raquiraa 
taatablllty. 

DEVELOPER:  Rasaarch  Triangla  Inatituta  (RTI) 

COMMENTS;  Uaafulnaaa  of  TEA  will  Inoraata  aubatantlally  upon  tha  oomplatlon 
ofEnhancadTEA, 

Enhancad  TEA  concaptually  haa  tha  following  additlona: 

•  Fully  populatad  DFT  rulaa.  BIT  taohniquaa.  and  BIT  modulaa  data 

baaa. 

-  Fully  automatad  Al-baaad  modula  Intarfaolng. 

•  Fault'tolaranoa  daaign  capability 

•  Daaign  for  prognoatio  capability. 

•  Extanalon  of  TEA  for  Monolithic  MIorowava  intagratad  Ciroulta 
(MMIC)  to  ba  known  at  TEAM. 

Intarfacaa  to  TI8S8  (Inoludad  In  thia  aaotlon). 

REFERENCES; 

1.  ADAS  Markating  Coordinator 
Cantarfor  Digital  Syatama  Raaaaroh 
RMaaroh  Triangla  Inatituta 

P.O.  Box  12104 

Raaaaroh  Triangla  Park,  NC  27709 
(910)541-7436 

2.  Army  Point  of  Contact 
U.8.  Army  •  CECOM 
Attantlon:  AMCPM-TMOE-LT 
Ft.  Monmouth,  NJ  07703 
(201)532-1447 
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3^4  TWM 

NAME:  TI888  *  Ttttvr  In  Support  Softwaro  Syattm 
YEAR:  1988 

FUNCTION:  Th«  primary  f  TISSS  la  to  automata  tha  ganaratlon  and 
maintananoa  of  product  apt  and  taat  pro^rama  for  Vary  Hlgh'Spaad 
Intagratad  CirouHa  (VH8IC)oomptax  Vary  Larga-Soala  Int^ratad  (VLSI) 
davloaa. 


To  aeoompllah  0  providaa  a  maana  of  oapturlng  oomputar- 
alolad  daaign  (CAD)  data  aoduot  apaolfloatlona.  TISSS  alao  alda  In  tha 
ga<iaration  of  thaaa  data  aaapturad.  tha  data  la  automatloally  loadad  Into 
tha  TISSS  data  baaa,  a>hantalnad  In  a  atandardixad,  tranaportabla,  and 
oomputar-aooaaalbla  formdata  aata  ara  aooaaaad  by  TISSS  to  ganarata 
product  apaolfloatlona  and  ma»  TISSS  alao  providaa  toola  for  validating 
tha  data  aata  to  anaura  oor  of  data,  proper  ayntax,  aamantloa.  and  data 
Intent. 


CAPACITY: 

CPU  TIME: 

APPLICATION:  YLSl  PCS 

ACQUISITION  PHASE:  CCM/VAL  PSD  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?  ^(Ql 

DESIGN  ENV:  TISSS  la  ayatam  written  In  Ada.  Although  daaignad  to 
be  portabla,  with  minimal  na,  TISSS  waa  davalopad  on,  and  uaaa,  tha 
faaturaa  of  tha  Digital  Edorporatlon  VAX  oomputar  ayatama.  Tha 
minimum  TISSS  hardwara/quiramanta  ara: 

0  Micro  Vax  111  floating  point  ooprooaaaor,  or  a  VMS* 
oompatibla  Dth  higher  parformanoa 

0  Nacaaaary  e«(turaa 

0  6  MB  main  m' 

0  KDA60dlakc 

0  TK50  96MB1 
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. . .  .1  — .  . .  . . . . I 

0  DHV1 1  8*llnt  Mynohronout  multlpl«x«r 

0  DItgnostlos  and  hardwart 

0  RA81  'EA  thraa  diaka  In  taoond  40"  oablnat;  diak  capacity  456  MB 

taoh 

0  VT240  graphica  tarmlnal 
0  MIoroVMa 
0  Ada  Lloanaa  (DEC) 

0  Oracia  Data  Baaa  Managamant  Syatam  Lloanaa  (Oraola  Corp.) 

0  Taat  Daaorlptlon  Macro  Skalaton  Lloanaa  (DEC) 

0  PALETTE  grahloa  lloanaa  (Paiatta  Corp.) 

OPTIONAL: 

0  HITS  (govammant  fumlahad) 

0  HILO  (QanRad  Corp.) 

0  VMDL  Support  Environment  (govammant  fumlahad). 

An  aatimata  of  tha  on*llna  dIak  atoraga  naoaaaary  for  an  oparatlonal  TISS8  ayatam 
la  baaad  on  tha  following  tabla; 

STORAGE  SIZE  IN  BLOCKS 
(Blook«612  bytaa) 


Itam 

TISSS  axaoutabla  coda 
Ml  axaoutabla 

On-llna  aoftwara  uaara  manual 
All  TISSS  dooumantatlon 
HILO  aimulator  axaoutabla 
HITS  aimulator  axaoutabla 
VHDL  analyzar  axaoutabla 
Oraola  aoftwara  library 
PALETTE  axaoutabla  coda 
TDMS 


Raquirad  Optional 

21,000 

18,000 

5,000 

73,000 

34,000 

19,000 

16,000 

22,500 

6,600 

23,000 
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TISSS  dttt  bM«  working  arta 
(20K  gataa,  on#  dtvica)  550.000 

VHDL  dasign  library  (tranalant) 

Tast  vaotor  (tranalant) 

Paging  apaoa 

(20K  gata  davice,  tingla  uaar)  300,000 


TOTAL  1,148,6000 

Blocks 

or 

574.3  Mb 


REFERENCES; 

Point  of  Contact; 

Bill  Ruaiall,  RADC/RBR 
Qrlfflas  AFB,  NY 
316/330-3974 


20,000 

50,000 


202,000 

Blocks 


106  Mb 
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3.2.5  Printed  Circuit  Board  Tottablllty  Dcolgn  Quid#  and  Rating  Syatam 
NAME;  Printed  Circuit  Board  Taatablllty  Daaign  Quida  and  Rating  Syatam 
YEAR; 

FUNCTION:  A  methodology  was  davalopad  during  an  Air  Foroa^aponaorad  study 
that  aoourataly  avaluatas  tha  taatablllty  marlts  of  a  printed  circuit  board  (FOB). 
This  Is  aocompllshad  through  a  *Figura  of  Marlt*  rating  system  that  weights  tha 
"difficult  to  test*  and  "easy  to  test"  aspects  of  a  circuit  design. 

Tha  principal  output  of  this  study  Is  an  axtanslva  Testability  Design  Quids  that 
describes  how  testability  problems  associated  with  circuit  structure  can  be 
oorraotad.  The  design  guide  works  hand*ln<hand  with  tha  rating  aystam  so  that  tha 
rating  system  Identifies  tha  nature  and  extant  of  tha  currant  taatablllty  problem,  and 
tha  guide  provides  tha  means  to  oorraot  tha  design  daflolanolas. 

CAPACITY;  N/A 

CPU  TIME:  N/A 

APPLICATION:  VLSI  £&&  SUB8YS  SYSTEM 
PUBLIC  DOMAIN?  ^/N 
DESIQN  ENV:  N/A 
REFERENCES: 

Consolla,  W.M.,  Danner,  F.Q.,  *An  Objective  Printed  Circuit  Board 
Testability  Design  Quids  and  Rating  System",  Rome  Air  Development 
Center  (RADC)  Technical  Report  TR>79*327,  January  1980. 


C-77 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


3.3  DIagnostle  Authoring  Tools 

This  ssotlon  lists  softwsrs  design  systems,  ss  well  as  software  tools,  that 
are  either  available  or  under  development  to  aid  In  the  design  and  development  of 
an  effective  diagnostic  system. 

Diagnostic  Authoring  Tools  may  be  further  subdivided  Into  two  (2)  major 
categories:  Generic  Diagnostic  Authoring  Tools  and  Automatic  Test  Generation 
Tools.  Information  pertaining  to  each  of  these  tool  types  Is  provided  In  the  ensuing 
paragraphs. 

3.3.1  Qenerlo  DIagnoetio  Authoring  Toole 

Those  types  of  tools  are  predominantly  concerned  with  authoring 
optimized  test  sequences,  techniques,  procedures,  or  teohnioal  Information  In 
support  of  the  diagnostio  design  process. 

Tools  that  aid  In  diagnostics  authoring  during  design  and  development 
have  the  following  features  In  common: 

•  They  are  useful  during  more  than  one  acquisition  phase  and  apply  to 
more  than  one  level  of  Integration. 

•  They  apply  to  a  variety  of  hardware  technologies.  Including  analog 
and  digital  circuitry. 

•  They  are  all  versatile  and  capable  of  many  design  aeslst  functions. 
That  function  capability  relative  to  this  document  being:  assisting  In 
the  various  authoring  tasks  required  to  design  and  evaluate  a 
diagnostio  capability. 

A  summary  description  of  tools  that  aid  In  diagnostio  authoring  during 
design  are  provided  an  the  following  Table: 
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ACRONYM 

APPLICATION 

PRIMARY  DIAGNOSTIC 
DB8IQN  ASSIST 
FUNCTION 

comment? 

OATA 

VLSI/AOI/ 

tUISVSTIM 

OFTOUIDANOI;  FI 

STRATSOY:  ■nr  ANALYSIS 

ANOATQ 

APPLIOASLITO: 

-  INOOMINO  INST 

•  MPOTISTINO 
.SYSTIMMPOTIST 

•  PRDOTNVIRIPIOATION 
’SYS  MAINTAINABILITY 

QIMAD$ 

DIAaNOtriO 

LIIAAAy 

VLSI/AOB/ 

iUISVSTIM 

RiraMNOISOUROI 

SORFISTRATIOIU 

IDBALTOUSI  IN 
CONJUNCTION  WITH  PMIA 
DIVtLOPMINT 

loss -ADA 

SUMYST8M/ 

■VSTIM 

AUTHOR  OlAONOtTIO 

Runs  AND  RROORSS 
ANOOIYILORTIST 

RROOIOURIt 

PUNOTtONSASASRIDOl 

TO  PASS  INPO  PROM 

DISION  TO  SUPPORT 

IDSS-TIATA 

POMUMYtTIM 

SYSTSM 

PROV10ISINTIRRAOI 

PORAUTHORmOITOR 

PORORIATSMIOR 

TIOHNIOALTRAININO 

MATIRIAL 

DISSSMINAT10N0P 
TSOHNIOAL INPORMATION 

TaUKSIS 

POMUMYSTIM 

PROVIOIStlSTNIXT 

TISTRIOOHMINOATION 

PORTRSDIYILOPMINT 

TOIR ISAPROORAM 
UTIIZINO  PIS,  A 
aSNBRAL  DIAONOSTIO 
KNOWLIDQI’SASIO  IXPIRT 

SYtTIM 
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NAME:  CATA  •  Computer  Aided  Testability  Analysis 
YEAR:  1983 

FUNCTION:  CATA  provides  OFT  guidance,  FI  strategy,  and  automatic  generation 
of  test  list  after  TY  evaluation. 

CATA  Is  applicable  to  Incoming  Inspection,  manufacturing  test,  system 
manufacturing  test,  prcductlon  verification,  and  system  maintainability. 

CAPACITY:  (Typical)  5  to  16  PCBs  with  400  ICs  of  SSI  to  LSI  con.plexlty. 

CPU  TIME:  30  min  for  above  capacity 

APPLICATION:  VLSI  E£i  SUB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N 

DESIGN  ENV:  VAX  11-780;  written  In  Pascal 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE: 

DEVELOPER:  Etudes  et  Productions  Schlumberger 

COMMENTS:  CATA  applies  to  digital  and  analog  circuits. 

New  developments  of  the  system  were  terminated  In  1986.  CATA  Is  an  Internal 
testablllt/  analysis  program  and  is  not  marketed  as  a  product  by  Schlumberger. 

REFERENCES: 

1 .  Robach,  Ch.,  P.  Malecha,  and  Q.  Michel,  "Computer-Aided  Testability 
Evaluation  and  Teat  Generation,"  IEEE  International  Test  Conference 
1983 

2.  Robaoh,  Ch.,  P.  Malecha,  and  G.  Michel,  ”  CATA:  A  Computer  Aided 
Test  Analysis  System,"  IEEE  D&T  of  Computers,  May,  1964 
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3.3.1 .2  QIMAD8  Dlignottic  Library 

NAME:  QIMAD8  DIAGNOSTIC  LIBRARY 

GIMADS  •  Qanarlc  Integrated  Maintenance  Diagnostics  Program 

YEAR: 

FUNCTION;  An  effective  method  of  classifying  and  referencing  diagnostic 
techniques  making  a  wealth  of  diagnostic  strategies  readily  available  to  planners  of 
new  systems.  The  library  is  In  spreadsheet  format  and  looks  very  similar  to  an 
FMEA.  In  fact,  a  description  of  the  component  and  Its  corresponding  failure  mode 
are  two  of  the  five  columns  provided  on  the  spreadsheet.  The  other  three  columns, 
which  refer  to  the  diagnostic  tsohniques  associated  with  detecting  and  Isolating  the 
described  component  In  each  of  Its  given  failure  modes,  are  as  follows: 

-  DIAGNOSTIC  TECHNIQUE:  A  small  selection  of  possible  test 
techniques  Is  provided  In  this  column. 

-  IMPACTS;  This  column  relates  the  Impact  Oa*!  skill  level,  reliability, 
cost,  etc.)  that  each  particular  technique  has  on  the  system. 

'  COMMENTS;  Included  in  this  column  are  pertinent  facts  that  may 
help  the  designer  during  the  selection  process. 

CAPACITY:  N/A 

CPU  TIME:  N/A 

APPLICATION:  VLSI  ESi  8UB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESE  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (QFE) 

DESIGN  ENV:  Pencil,  paper,  and  calculator. 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE:  Ample  definition  or  description  of  the  system  requiring 
diagnostic  authoring. 

DEVELOPER;  GIMADS  •  General  Dynamics  team  under  contract  from  US  Air 
Force. 
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COMMENTS:  It  would  bt  •  good  Idoa  to  fill  In  aomo  FMEA  data  whilt  working  with 
tha  QIMAOS  DIagnoatIo  Library.  If,  tharafore,  a  diagnostic  taohnlqua  la  aalaoted 
from  tha  library  for  a  particular  failure  moda  of  a  particular  eomponant,  than  50 
parcant  of  tha  FMEA  procasa  would  also  ba  complatad  at  tha  aama  tima. 

Enginaaring  analysis  la  still  raquirad  to  maka  sura  that  tha  bast  salactlon  offarad  by 
tha  library  la  tha  bast  salactlon  for  tha  system  being  davalopad. 

Often  a  test  technique  will  detect  many  failure  medas  of  many  components.  In  this 
ossa  much  of  tha  information  In  tha  library  need  not  ba  rafaranoad. 

REFERENCES: 

1.  QIMADSTaam 
General  Dynamics 
MZ140e 

P.O.  Box  748 

Ft.  Worth,  Tx.  76101 

(817)762-2204 

2.  Air  Force  Point  of  Contact 
ASD/ENE  (QIMADS) 

Wright-Pattarson  AFB,  Ohio  45433 
(513)  256-2609/4428 
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3.3.1 .3  IDSS-ADA 

NAME:  ID88  •  ADA  -  Adaptive  Diagnostic  Authoring 
YEAR: 

FUNCTION:  Performs  those  functions  neoessary  to  ensure  the  conversion  of  test 
strategies,  procedures  and  heuristics  Information  into  a  form  suitable  for  use  by  the 
on-line  diagnostician.  The  ADA  will  perform  the  following  tasks: 

•  Process  WSTA  output  for  entry  Into  the  weapon  system  knowledge 
and  data  bases. 

-  Receive  fault  pattern  Information  from  a  test  engineer  and  add  it  to 
the  fault-symptom  table  of  the  weapon  system  knowledge  base,  as 
well  as  autlior  additional  diagnostic  rules. 

-  Process  developed  teat  procedures.  This  Includes  developing  result 
descriptions  of  the  test  procedures  for  the  weapon  system  data  base 
and  adding  the  test  procedure  code  to  the  test  procedure  library  that 
is  accessed  during  fault  isolation. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  tOi-  SUB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESC  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (QFE) 

DESIGN  ENV: 

CIRCUIT  DESCRIPTION:  N/A 
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USE  PREREQUISITE:  Tht  ADA  will  prooMS  th«  following  typo  of  inputs: 

-  WSTA  outputs  Including,  dspsndsncy  model  representation, 
candidate  search  strategies,  and  logistic  data  (e.g.,  MTBP). 

-  Test  procedures.  All  non>IOSS  test  procedure  generators  must 
provide  executable  code  and  a  description  of  the  results  of  the  tests. 

•  Fault  pattern  Information. 

DEVELOPER:  Harris  Corporation  under  contract  from  the  US  Navy. 

COMMENTS:  Together,  the  ADA  and  TIATA  provide  a  bridge  for  passing 

Information  between  the  design  and  support  clusters. 

REFERENCES; 

1 .  Dr.  Bruce  J.  Rosenburg,  "The  Navy  Integrated  Diagnostic  Support 
System  •  System  Overview,  Architecture  and  Interfaces,"  IEEE 
AUTOTESTCON  1987. 

2.  Navy  Point  of  Contact 
NAVSEa  •  Code  CEL-DS 
Washington,  DC  20362-6101 
(202)  602-2036/2036 
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3.3.1 .4  ID88-TIATA 

NAME;  ID88  -  TIATA  <  Ttohnical  Information  And  Training  Authoring 
YEAR: 

FUNCTION:  Enaurai  tha  oonvaralon  of  daaign  Information  Into  taachabla  format 
suitable  for  use  by  the  on*l!ne  diagnostioian.  The  TIATA  Is  dedicated  to  the 
following  tasks; 

-  Paperless  dissemination  of  technioal  Information. 

•  Provide  an  Interactive  Interface  for  an  author/editor,  which  can  be 
used  to  create,  view  and  edit  technical  Information  and  training 
tutorials  consisting  of  a  combination  of  text,  graphics,  and  audio* 
vlaual  material.  The  technical  Information  and  training  tutorials  can 
be  hlerarohloaliy  structured  which  promotes  thoroughness  of 
Instruction  while  reducing  redundancy  In  the  training  process. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  Efifi  8UB9Y8  8Y8TF.M 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  EgR  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (QFE) 

DESIGN  ENV; 

CIRCUIT  DESCRIPTION:  All  technical  Information  Is  In  IQES. 

USE  PREREQUISITE:  The  TIATA  will  process  various  documentation  sources. 

DEVELOPER:  Hanis  Corporation  under  contract  from  the  US  Navy. 

COMMENTS:  Together,  the  ADA  and  TIATA  provide  a  bridge  for  passing 
Information  between  the  deeign  organization  and  the  user  In  the  field. 


The  TIATA  provides  two  types  of  Instruction,  quick  Instruction  for  step-by-step 
guidance  during  an  on-line  diagnostic  procedure,  and  broader  Instruction  for  study 
and  maintenance  skill  development. 
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REFERENCES: 

1.  Dr.  Bruct  J.  RoMnburg,  "The  Nivy  Integrated  Diagnoitic  Support 
System  •  System  Overview.  Arohiteoture  and  Interfaces,"  IEEE 
AUTOTESTCON  1967. 

2.  Navy  Point  of  Contact 
NAV8EA  •  Cede  CEL-DS 
Washington,  DC  20362*5101 
(202)  692*2035/2036 
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NAME:  TQIR  Ttst  Qvntritor  Inferrad  Rtaaoning 

ns  •  Fault  Isolation  Shall 

YEAR:  1987  (prototypa) 

FUNCTION:  TGIR  it  a  Navy  tpontorad  program  staking  for  Al  solutions  to  TPS 
davalopmant,  Tha  prototypa  systam  davalopad  by  tha  TQIR  program  usas  FIS  (a 
softwara  syatam  davalopad  for  ganaral  diagnosis  Raf[1])  for  tha  ganaratlon  of  fast 
prooadurat,  typically  raprasantad  as  diagnostio  flowoharts.  Although  tha  systam 
naads  to  ba  raflnad,  a  knowladga*basad  axpart  syatam  has  baan  damonatratad 
with  tha  following  oharaotartatloa: 

•  Tha  Initial  knowladga  bast  is  oomprisad  of  oollactad  Information  or 
facts  which  dasoriba  tha  spaolflo  UUT  (may  ba  attalnad  from  CAD 
data  basa)  and  tha  UUT  problama  or  symptoms. 

•  Tha  Infaranoa  angina  continuas  to  davalop  tha  knowladga  basa  by 
conducting  an  intaraotiva  dialogua  with  tha  last  oparator  and/or  the 
ATE  system. 

•  Tha  Infaranea  angina  performs  a  search  and  pattern  match  to  salaet 
tha  appropriate  test  or  fault  diagnosis.  Whan  tha  fault  diagnosis 
routine  stalls  due  to  Incomplete,  ambiguous,  or  oontradlotory  data, 
additional  data  Is  raquastad  from  tha  teat  operator  or  ATE  system. 

•  Tha  rule  basa  will  ba  partitioned  Into  several  parts.  One  part  may  ba 
a  generic  troubleshooting  prooadura  and  one  part  a  spaolflo 
pi'ooadure  as  dalagatad  by  tha  UUT's  TRD.  Other  parts  may  ba  tha 
UUTa  failure  history  or  a  functional  description  of  tha  UUT. 

CAPACITY:  N/A 

CPU  TIME:  Tha  time  to  derive  a  'bast  next  test*  recommendation  can  taka  seconds 
to  minutes,  depending  on  the  complexity  of  tha  UUT. 

APPLICATION:  VLSI  P£B  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (QFE  most  likely) 

DESIGN  ENV:  Tha  prototypa  has  baan  Implamantad  In  LISP.  FIS  runs  on  Sun  and 
Vax  workstations  with  planned  capability  to  njn  on  Symbolics  and  ISI  workstations. 


C-07 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


. . . . . .  .  .  I 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE:  FIS  rtquirai  ft  Hat  of  toata  bafor*  It  can  rocommond  what 
tftat  to  parform  naxt.  A  'qo  chain*  la  alao  raquirad  In  order  to  verify  normal 
operation. 

DEVELOPER;  NAVAIR  Engineering  Center  la  developing  TIGR  and  Naval 
Reaearoh  Lab'a  Navy  Center  for  Applied  Reaearoh  In  Artificial  Intelligence  la 
developing  FIS. 

COMMENTS:  TIQR/FIS  appilea  to  analog/digital  circuitry. 

TIQR  blackboard  architecture  needa  to  be  developed  to  determine  next  beat  teat  to 
perform. 

There  are  15  to  20  other  programa  bealdea  TIQR  utilizing  FIS  aa  a  dlagnoatlc 
reaaoning  aid. 

Cauaai  modeling  and  heuriatic  aearoh  are  the  dominant  Inference  teohniquea  uaed 
by  TIQR/FIS. 

The  teohniquea  uaed  by  knowledge  engineera  will  have  a  great  Impact  In 
determining  whether  or  not  Al  will  provide  auooeaaful  aolutlona  aought  by  the  ATE 
community.  SeeRef[3]. 

REFERENCES: 

1.  F.  Pipitone,  "The  FIS  Electronic  Troubleshooting  System,"  IEEE 
Computer  magazine,  July  1986,  pp  68-76. 

2.  Kenneth  A.  Porter,  Jr.,  "Al  Applications  to  Automatic  Testing:  Trend 
For  the  Future,"  AUTOTESTCON  87  pp  377-382. 

3.  Jerry  L.  Kunert,  "Knowledge  Engineering,"  AUTOTESTCON  86  pp 
169-164. 

4.  Navy  Point  of  Contact 
Navy  Air  Engineering  Center 
Code  901 3E 

Lakehurst,  New  Jersey  08733-5000 
(201)  323-2462/2648 
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3.3.1 .6  AI-TE8T 

NAME;  AI-TB8T  •  Arilflolal  Inttlligtnoa  Teat 
YEAR:  1987  (Commarolelly  available) 

FUNCTION:  ATTEST  (formally  ATEX  -  eee  Ref [2])  la  an  expert  ayatem  that  offera 
the  following  aaalatanoe  during  the  teating  prooeaa: 

•  Rahka  modulea  according  to  their  likelihood  of  being  the  oauae  of 
failure. 

•  Suggeata  diagnoatio  goala  for  the  next  etage  of  teating. 

-  Identiflea  and  evaluataa  teata  which  may  be  uaed  In  achieving  the 
diagnoatio  goala  and  propoaea  the  moAt  ooet  effMtIve  teat. 

CAPACITY:  MS*D08  veralon  up  to  100  modulea;  UNIX  veralon  up  to  1000 
modulea. 

CPU  TIME:  The  time  to  derive  a  'beet  next  teat*  recommendation  can  take 
aeconda  to  minutea  depending  on  the  complexity  of  the  UUT. 

APPLICATION:  VLSI  E2fi  9UB3YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  fgP  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  (PRTY) 

DESIGN  ENV;  ATTEST  haa  been  Implemented  In  the  ”0"  language  (t  part  of  the 
Inference  engine  waa  prototyped  In  PROLOG)  and  can  run  on  an  MS*DOS  baaed 
computer  (e.g.,  an  IBM  PC/XT  or  AT,  HP  Veotra,  Compaq)  which  may  be 
Interfaced  to  an  ATE  minicomputer,  be  embedded  In  a  UNIX  baaed  ATE 
minicomputer  (HP  350)  or  be  operated  Independently  In  manual  teating. 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE;  The  uaer  muat  create  a  UUT-apecIflo  knowledge  baae 
which  Includea  the  unique  atruoture  and  oharaoterlatloa  of  a  given  UUT,  and  the 
teat  available  to  diagnoee  It.  Specifically,  for  any  given  UUT  one  muat  supply  the 
following  Information  In  order  to  generate  the  UUT«speclflc  knowledge  baae; 

-  The  block  diagram,  which  oonalata  of  elementa  (modulea,  ports. 
Junctions,  test*polnts)  and  links  (wires,  buses)  between  these 
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•l•mtnt8.  For  oaoh  modulo,  oovorol  paromotort  aro  noodod 
Including  Ita  falluro  rata  (If  known),  dogroo  of  orltloallty,  and  whether  It 
belongs  to  one  of  the  families  In  the  ALTEST  library. 

•  The  set  of  tests  defined  for  the  UUT.  For  each  test,  the  user  provides 
a  desorlptlon  of  Its  path  and  the  measurements  taken  at  Its  output 
points. 

>  For  a  unit  with  1 00  modules  and  80  •  1 00  teats,  UUT  preparation  may 
take  120  hours. 

DEVELOPER:  Intelligent  Electronics,  Inc.  (See  Ref.) 

COMMENTS:  ATTEST  applies  to  analog/digital  circuitry. 

« 

Desidea  the  UUT*speolfled  knowledge  base  which  la  built  by  the  user,  Al-TEST 
contains  a  general  purpose  knowledge  base.  This  base  encompasses  knowledge 
related  to  electronic  theory.  Including  knowledge  about  different  kinds  of 
measurements  (DC  voltage,  frequency,  etc.),  and  a  library  of  functional  level 
element  families  (A/0  converters,  amplifiers,  etc.). 

The  user  may  request  AI-TEST  to  explain  Its  line  of  reasoning. 

Summary  reports  may  be  viewed  on  the  display,  printed  out  In  hard  copy,  or  stored 
In  a  file.  Such  files  are  later  used  for  learning  purposes  In  order  to  Improve  the 
UUT  knowledge  base.  Data  base  tools  are  Included  for  data  management  of 
UUTa. 

In  an  ATE  environment,  ATTEST  may  be  Interfaced  to  the  ATE  computer  via  R8> 
232  or  IEEE-488  Interface.  Through  this  link,  a  fully  automatic  test  system  may  be 
obtained  where  AI-TEST  oommunloates  wHh  the  test  executive. 

As  time  goes  on,  AI-TEST  will  reach  higher  levels  of  comprehensive  and  correct 
diagnostic  assessment. 
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REFERENCES: 

1.  M.  Ban'Basttt,  at  al.  *A  Caaa  Study  With  ATTEST:  An  Expart 
Syatam  For  Elaotronic  Troublaahootlng,”  IEEE  AUTOTESTCON, 
1M7. 

2.  M.  Bari’Baaaat,  *Expart  Syatama  for  ATE  tha  ATEX  Approach,"  IEEE 
AUTOTESTCON.  1985. 

3.  lET  •  IntalHoant  Elaotronlca  Ino. 

UEaaarTaohanotSt. 

Ramat  Maohayal,  Tal  Aviv 

laraal 
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3.3.2  Automatto  TMt  Qanaratlon  Authoring  Tools 

This  aactlon  contains  aoftwara  tools  avallabla  that  are  a  subset  of  tools 
that  aid  In  diagnostic  authoring.  In  particular,  they  aid  In  authoring  or  generating 
digital  tost  vectors. 

They  are  called  Automatic  Teat  Qenerators  (ATGs)  or  Automallc  Test 
Pattern  Qenerators  (ATPQs). 

Automatic  Test  Generation  (ATQ)  and  fault  simulators  go  hand'ln^hand 
and  sometimes  are  one  In  the  same  tool.  However,  for  classification  purposes, 
fault  simulators  can  be  found  In  the  Section  for  Testablllty/Dlagnostio  Assessment 
Tools  (Section  4.2)  under  the  subheading  called  Diagnostic  Effectlvsnesa 
(Prediction). 

A  simulator  Is  a  software  program  which  provides  a  simulation  of  the 
normal  (I.e.,  no*fault)  behavior  of  Internal  circuit  nodes  and  primary  outputs  In 
response  to  stimuli  applied  to  Its  Inputs.  Simulators  are  very  Important  design  tools 
and  are  one  Instrumental  aid  In  the  dealgn/development  of  modern  digital  systems. 
Most  simulators  provids  a  fault  almulatlon  capability.  Fault  simulation  Is  a 
simulation  of  a  circuit  In  the  presence  of  a  fault.  The  fault  Introduced  la  chosen  to 
be  compatible  with  the  particular  oharaoterlatlos  specified  by  a  fault  model  for  a 
particular  device  (I.e.,  atuoK  at  *0”  or  stuck  at  *1*).  Most  units  under  test  contain 
many  fault  possibilities.  Most  fault  simulation  systems  will,  On  demand, 
automatically  Inject  faults  ons«by«one  Into  a  UUT,  so  that  the  user  can  ascertain  the 
effect  of  these  faults  In  response  to  a  given  test  vector  stimulus  Input  to  the  UUT. 
A  fauK  Is  oonsidered  "detected"  If  the  response  of  the  circuit  Is  visibly  different  from 
the  good  circuit  with  respect  to  the  stimuli  applied.  Implicit  In  fault  almulatlon  Is  the 
capability  to  compare  a  good  circuit  simulation  against  faulty  circuit  behavior. 

Automatic  Test  Generators  (ATGs)  or  Automatic  Test  Pattern  Qenerators 
(ATPQs),  as  they  are  sometimes  referred  to,  typically  employ  both  fault  simulation 
and  test  pattern  generation  capability.  After  a  fault  simulation  Is  mn  In  response  to 
a  given  test  vector  stimulus,  the  ATPQ  examines  which  faults  remain  undetected 
and  tries  to  determine  what  new  test  vectors  need  to  be  applied  to  the  UUT  to 
detect  those  previously  undetected  failure  modes.  The  process  of  "generating" 
new  test  vectors  Is  called  teat  generation.  ATPGs/ATQs  are  used  to  automate  this 
process.  However,  even  relatively  simple  sequential  circuits  can  be  extremely 
difficult  for  an  ATPQ/ ATQ  algorithm  to  analyze  and,  subsequently,  to  generate  test 
patterns.  Practically  speaking,  most  tests  ere  for  the  most  part  derived  "manually," 
often  by  trial  and  error,  utilizing  a  fault  simulator  for  data  feedback  analysis. 

The  digital  test  vector  "authoring  process”  concludes  when  1 00  percent 
of  the  faults  In  the  UUT  fault  list  are  detected. 
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Both  types  of  tools  (I.e.,  ATPQ/ATQ  and  fault  simulators)  are  essential  to 
the  design  and  evaluation  of  an  effective  diagnostic  system. 

Many  systems  that  do  not  plan  to  Include  a  particular  diagnostic 
capability  as  part  of  the  design  process,  deploy  ATQs  simply  because  they  make 
the  production  validation  process  economically  feasible.  However,  these  tool 
capabilities  very  much  serve  In  the  assistance  of  Including  diagnostic  capabilities. 
For  example,  they  may  be  useful  during  the  Deployment  Phase  within  the  repair 
oyoie,  for  developing  BIT  routines,  or  for  fault-tolerant  design  and  evaluation. 

Tools  that  aid  In  automatic  test  generation  all  have  the  following  features 
In  common; 

•  They  would  be  deployed  during  the  Pull  Scale  Development  Phase 
for  the  purpose  of  deriving  an  effective  and  optimized  set  of  test 
vectors  necessary  to  perform  the  task  of  validating  the  functional 
design  during  production. 

-  They  all  apply  to  digital  circuitry  and  primarily  process  faults  at  the 
gate  level. 

••  Although  each  tool  Is  capable  of  being  run  separately,  ATQs  and  fault 
simulators  are  almost  always  run  together.  The  ATQ  provides  the 
test  vector  set.  The  fault  simulator,  either  statistically  or 
deterministically,  evaluates  what  percentage  of  the  total  faults 
considered  would  be  detected  by  such  a  test  vector  set. 

•  Speed  enhanoemer'.t  ie  this  family  of  tools  prime  competitive  sport 
and  each  has  a  unique  way  of  remaining  In  the  arena.  Refer  to  the 
following  chart  with  the  column  headed,  'INCREASED  SPEED 
METHOD." 

A  summary  description  of  tools  that  aid  In  test  generation  authoring 
during  design  are  provided  In  the  Table  below: 
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ACRONYM 

APPLICATION 

INCREASED  SPEED 
METHOD 

COMMENTS 

AIDA 

VLSI/PCB/ 

Subtytitm 

A  RISC  CO  ilmulalor 

It  mountid  Into  lha 
wofluUUon 

PrevMaa  axoaMant 
aoandaiign 

aaaiatanoa 

HITS 

VLSIPCB 

UiM  eonourftnl 
•Imulallon 

AtalalaInTPS 

davalepmani 

LASAR  VER  S: 
PROSECUTOR 

VLSI/PCB 

Concumnt 

Sknuiatlon 

Pest  proeattlng 
avallabla  to  maKa 
stimuli  eompadbla  with 
laigattoalar 

SOCRATES 

VLSI 

UtM  an  Improvad  ATQ 

Ian  algorittim  t  an 
affleiani  taul 
almiEatlon  apfroaoh 

Canlaa  Information 
hauriitloally 

Irom  TV  Analytit  to 
ATO  proeata 

THESEUS 

VLSI/PCB 

Aftai  aaeh  toat 
vacter,  atidataetod 
laula  ara  no  lengar 
eonaUarad 

Prauldaa  an 
akamatlva  to  aean 
daalgn 

rVCAD; 

NtxtQan 

VLSt/PCB/ 

Subiytlam 

Sknutatlen  ItTglamantad 

In  hatAaara  amfitoylng 
paraM  pipallna 
proeaaaing  laehniquaa 

ZVOAD'aNoxtOan 
la  an  aoealafatad 

ATO 
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3.3.2.1  AIDA 
NAME:  AIDA  ATPQ 
YEAR:  1987 

FUNCTION:  As  part  of  an  Integrated  set  of  testability  tools,  the  AIDA  ATPQ  works 
In  conjunction  with  the  AIDA  fault  simulator  and  automatic  scan  generator  to  reduce 
the  "testability  overhead"  during  SCAN  design  and  speeds  up  the  generation  of  test 
vectors  for  manufacture.  ATPQ  creates  vectors  to  detect  manufacturing  defects  and 
can  achieve  100  percent  coverage  of  the  detectable  single  8tuck>at  fault  In  a  SCAN 
design.  When  used  In  conjunction  with  the  AIDA  fault  simulator,  the  set  of  required 
test  vectors  can  be  reduced  to  a  small  number.  Often  only  a  few  hundred  test 
vectors  are  required  to  adequately  test  a  30K  gate  design. 

Refer  to  Section  4.2.2.1  for  more  Information  on  AIDA. 
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3.3.2.2  HITS 

NAME;  HITS  -  Hierarchical  Integrated  Test  Simulator 
YEAR:  1987 -HITS  14 

FUNCTION:  HITS  Is  a  Digital  Automatic  Test  Program  Generator  (DATPQ) 
software  system,  its  primary  function  as  a  software  tool  Is  to  assist  In  the 
development  of  digital  Test  Program  Sets  (TPS)  and  as  a  means  to  evaluate/verify 
digital  designs. 

Refer  to  the  section  on  fault  simulators  which  can  be  found  In  appendix  (4.2.2, 4) 
Testabillty/Dlagnostio  Assessment  Tools. 
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3.3.2.3  LASAR  VERSION  6  -  PROSECUTOR 
NAME:  LASAR  VERSION  6  •  PROSECUTOR 

YEAR;  1982,  origin  1978 

FUNCTION;  LASAR  Version  6  provides  a  CAD  simulation  system  for  design 
verification  and  test  program  generation  Incorporating  the  following  testability 
subprogram; 

PROSECUTOR  •  An  optional  component  of  LASAR  Version  6,  it  automatically 
generates  test  vectors  for  CMOS,  NMOS,  TTL,  and  ECL  gate  arrays,  standard 
SSI/MSI  parts,  fuse-programmable  logic  arrays  and  sequencers,  and  other  digital 
parts  of  similar  size  and  complexity.  It  uses  a  critical  path  sensitization  technique, 
generating  self-initializing  stimulus  vectors  which  cause  circuit  node  faults  to 
propagate  to  primary  output  pins. 

Testability  problems  such  as  non-lnitlallzable  latches,  redundant  circuitry,  and 
trIstate  outputs  which  need  pull-up  resistors  are  uncovered  In  the  process.  These 
problems  are  reported  so  they  can  be  evaluated  by  the  circuit  designer  who  can 
Interact  If  necessary. 

Refer  to  the  section  on  fault  simulators  which  can  be  found  In  this  appendix  (4.2.2.6) 
for  Testablllty/Dlagnostio  Assessment  Tools  under  the  subheading  called 
Testabillty/Diagnostic  Effectiveness  (Prediction)  and  also  to  this  appendix  for 
Testability/Diagnostic  Design  Implementation  under  the  subheading  called 
Architecture  (3.1). 
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3.3.2.4  SOCRATES 

NAME:  SOCRATES  •  Structure  Oriented.  Cost  Reducing,  Automatic  Test 

Pattern  Generation  System 

YEAR:  1988 

FUNCTION:  An  ATQ  system  providing  random  or  deterministic  test  patterns  for 
VLSI  with  scan  and  combinational  circuits.  It  promises  sIgnHIcant  cost  reductions  by 
combining  the  following  technical  improvements  to  Its  ATQ  process: 

-  It  uses  a  highly  efficient  fault  simulation  approach,  see  Ref[4]. 

•  It  Improves  upon  an  already  efficient  FAN  algorithm,  Ref[2],  using 
special  techniques  that  reduce  the  number  of  backtracinga  and 
recognize  conflicts  early. 

•  It  heurlstloally  carries -over  information  derived  from  the  testability 
analysis  and  applies  It  to  the  ATQ  process  (refer  to  HECTOR]. 

CAPACITY;  Over  100,000  prImHIves  on  an  Apollo  Domain  DN  4000 

CPU  TIME;  A  sample  circuit  (c7662  of  Ref  (3))  achieved  a  08.25%  fault  coverage 
when  231  test  vectors  (both  random  and  deterministic)  were  applied.  The  total  CPU 
process  time  took  284.3  seconds,  of  which  86.6  seconds  were  due  to  fault 
simulation  and  the  remaining  time  due  to  generating  test  vectors. 

APPLICATION:  VLSI  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSB  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 

DESIQN  ENV:  Part  of  the  SITEST  CAD/CAT  system.  The  above  example  was  run 
on  an  Apollo  DN  3000  workstation. 

CIRCUIT  DESCRIPTION;  Circuits  can  be  described  at  gate  level.  Including  XOR 
and  XNOR  gates,  or  can  bo  described  with  high-level  primitives,  e.g.,  adders, 
multiplexers,  demultiplexers,  encoders,  decoders,  etc.  Circuit  description  Is  based 
on  the  SMILE  Simulator,  Ref[5]. 

USE  PREREQUISITE:  SMILE  simulator  or  (at  least)  SMILE  circuit  compiler. 
DEVELOPER:  Siemens  •  AQ,  W.  Germany 
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COMMENTS:  SOCRATES  will  provide  the  following  outputs: 

•  List  of  faults  of  Interest 

•  aborted 

•  redundant 

•  undetected 

•  List  of  generated  teat  patterns 

•  The  backtrack  distribution  file 

•  A  summary  file  providing  Information  such  as  CPU  time,  fault 
coverage,  etc. 

SOCRATES  provides  an  option  to  generate  tests  for  only  a  given  set  of  faults. 

The  developers  of  SOCRATES  are  Investigating  more  possibilities  of  Improvement, 
for  example: 


•  Find  alternatives  to  random  patterns,  particularly  for  random  pattern 
resistant  circuits. 

•  Minimize  multiple  baoktraoes  while  maintaining  SOCRATES 
performance  In  terms  of  backtrackings  and  aborted  faults. 

•  Develop  techniques  that  would  automatically  choose  the  testability 
measure  that  would  achieve  good  performance  with  minimal  conflicts. 

•  Determine  If  dynamic  testability  measures  would  prove  beneficial. 

•  Further  Improve  upon  the  heuristics  employed. 

REFERENCES: 

1.  Schulz,  M.H.,  E.  Trlschler,  end  T.M.  Ssrfert,  "SOCRATES:  A  Highly 
Efficient  Automatic  Test  Pattern  Generation  System,"  IEEE  ITC  1987, 

pp.  1016*1026 

2.  Fujlwara,  Hideo  and  Takeshi  Shimono,  "On  the  Acceleration  of  Test 
Generation  Algorithms,"  IEEE  Transactions  on  Computers,  vol.  C  -  32, 
No.3.  pp.  1 137  •  1 144,  Dee.  1983. 

3.  Brglez,  F.  and  H.  Fujlwara,  "A  Neutral  Netlist  of  10  Combinational 
Benchmark  Circuits  and  a  Target  Translator  In  Fortran,"  Proo.  IEEE 
Int.  Sym.  on  Circuits  and  Systems;  Special  Session  on  ATPQ  and 
FauH  Simulation,  pp.  663  •  698,  June  1985. 
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4.  Antreich,  K.J.  and  M.H.  Schulz,  "Fast  Fault  Simulation  In 
Combinational  Circuits,”  IEEE  tnt.  Conf.  on  Computer  Aided  Design, 
ICCAD  - 1986,  Nov.  86. 

5.  Qonaueer,  M.,  Egger,  F.,  Frantz,  D.,  "SMILE  '  A  Multilevel  Simulation 
System,”  Proc.  1984  IEEE  ICCD,  pp.  188  - 193. 
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3.3.2.5  THESEUS 

NAME;  THESEUS  •  ATQ  With  Inheront  Tests^llity  Analyzer 
YEAR: 1986 

FUNCTION:  An  ATQ  system  capable  of  high  fault  coverage  for  complex  sequential 
circuits  without  need  to  change  design  for  testability.  There  Is  an  optional  Interactive 
testability  analyzer. 

CAPACITY:  260  K  nodes/chip 

CPU  TIME;  (Example)  3,585  vectors  for  a  highly  sequential,  function  controller 
circuit  took  116  min. 

APPLICATION:  VLSI  P£B  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  F8D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  (PRTY) 

DESIGN  ENV:  VAX  1 1/785;  part  of  CADAT  simulation  toolset 
CIRCUIT  DESCRIPTION:  HHB  System  unique 

USE  PREREQUISITE:  The  circuit  description  Is  a  simple  netllst  file  describing  the 
circuit's  parts  and  Interconnections.  This  file  Is  easily  generated  from  schematic 
capture  systems  using  netllst  translators. 

DEVELOPER:  HHB  Systems,  Mahwah,  N.J. 

COMMENTS:  THESEUS  Is  a  practical  alternative  to  scan  path  techniques  or 
complex  Testability  analyzers. 

Testability  reports  are  produced  which  contain  the  following  Information; 

>  List  of  zero,  one,  and  tri-state  CY  ior  each  node  In  the  circuit,  sorted  by 
node  or  value 

-  Histogram  displaying  nodal  CY 

-  List  of  nodes  that  cannot  be  controlled 
•  List  of  sources  of  un-CY 
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-  List  of  feedback  loops  that  cannot  be  initialized 

Test  vectors  produced  by  THESEUS  are  text  files  containing  the  stimuli  to  the 
circuit.  This  file  can  be  transported  to  the  user's  in<house  simulator;  or  using  the 
CADAT  simulator  option,  the  complete  test  program  consisting  of  stimulus  and 
response  data  can  by  generated, 

Upon  completion  of  the  test  generation  process,  THESEUS  provides  a  variety  of 
fault  analysis  reports  which  consist  of: 

•  Listing  of  all  faults  Including  the  detection  step  and  status  of  each 

•  Listing  of  faults  detected  by  test  step 

•  Listing  of  any  undetected  faults 

^  Listing  of  test  generator  performance  for  each  fault  selected 

THESEUS  takes  advantage  of  the  fact  that  a  test  for  one  fault  frequently  detects 
many  other  faults.  All  detected  faults  are  eliminated  from  the  data  base.  Control  Is 
then  returned  to  the  ATQ  engine  which  generates  vectors  for  the  remaining 
undetected  faults.  This  process  continues  until  all  the  faults  have  been  detected 
and  the  fault  data  base  is  exhausted. 

THESEUS  allows  reoonvergent  fan>out  structure  paths  to  be  simultaneously 
sensitized  without  excessively  burdening  the  test  generation  process. 

REFERENCES; 

1 .  Marlett,  Dr.  R.A.,  "An  Effective  Test  Generation  System  For  Sequential 
Circuits,”  IEEE  Design  Automation  Conference,  1 986. 

2.  Marlett,  Dr.  R.A.,  ”  A  Comprehensive  Test  Generation  Technique  For 
Highly  Sequential  Circuits,”  IEEE  Design  Automation  Conference, 
1978. 

3.  Also  see  CADAT  6 
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3.3.2.6  ZYCAD  N«xtG«n 
NAME:  ZYCAD  NextGen 
YEAR:  1985 

FUNCTION:  Perform  ATQ  taeke.  It  Implements  the  simulation  In  hardware 
employing  parallel  pipeline  processing  techniques.  This  affords  greater  speed  than 
possible  with  software  routines  which  must  retrieve  Instructions  from  external 
memory  and  execute  them  sequentially. 

COMMENTS  :  NextQen,  an  accelerated  ATQ,  features  an  enhanced 
Implementation  of  extended  backtrace  algorithm.  It  can  be  applied  to  devices 
containing  any  mix  of  combinational  and  sequential  logic  and  up  to  65,000  gates. 

NextQen  allows  for  fault  dictionary  or  guided  probe  fault  Isolation  and  enables  the 
user  to  focus  on  those  parts  of  the  design  that  may  be  untestable,  helping  to 
achieve  optimum  testability. 

NextQen  II  replaces  the  original  NextQen  and  Includes  many  enhancements  as 
follows: 

•  Speed  1 0  •  20  times  original  release  of  NextQen 

•  Fault  coverage  significantly  extended 

•  Features  added,  user  Interface  enhanced. 

NextQen  does  a  testability  analysis  of  the  network  prior  to  beginning  test  generation. 
With  the  addition  of  'Dynamic  Heuristics,"  NextQen  augments  this  Information  and 
continues  learning  about  the  circuit  during  the  test  building  process.  This  allows 
NextQen  to  better  choose  and  sensitize  paths  through  the  design.  Improving 
performance  and  minimizing  test  generation  time. 

Use  of  ZILOS,  a  friendly  simulation  environment,  promotes  the  use  of  the  same  data 
base  files  for  logic  simulation,  fault  simulation,  test  analysis,  and  test  generation. 
Refer  to  the  section  on  fault  simulators  (4.2.2.1 1)  In  this  appendix. 
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4.0  ASSESSMENT  TOOLS 

There  are  two  categories  of  tools  that  He  within  the  assessment  umbrella. 
Inherent  testability  analysis  tools  and  diagnostic  test  effectiveness  tools. 


4.1  Inherent  Testability  Analysis  Tools 

This  section  contains  various  tools  available  to  aid  In  the  task  of 
performing  an  Inherent  testability  analysis. 

There  are  no  claims  made  that  this  Is  an  all  Inclusive  list.  There  are 
perhaps  dczens  of  tools  that  are  not  Included  that  perform  bettor  or  equally  as  well 
as  some  of  those  described  here. 

The  Inherent  testability  analysis  tools  listed  In  this  section  all  have  the 
following  features  In  common: 

•  They  would  be  used  as  Inherent  testability  analysis  tools  during  the 
Full  Scale  Development  Phase,  with  the  possibility  of  being  useful 
during  the  Dem/Val  Phase. 

.  With  the  exception  of  IDSS/WSTA  and  STAMP,  they  all  apply  to 
digital  circuitry  only. 

•  They  measure  a  circuit's  testability  by  determining  controllability  and 
observability  factors. 

No  attempt  has  been  made  to  rank  these  tools.  Therefore,  they  are  listed 
In  alphabetical  order. 

A  summary  description  of  tools  that  aid  In  assisting  Inherent  testability  Is 
provided  In  the  following  Table. 

The  following  explains  the  column  headings  of  the  chart: 

TEST  PNT  ANAL/REC7:  A  "yes”  indicates  that  test  point  analysis 
and  recommendations  are  included  In  the  program. 

STATISTIC  ANAL?:  A  "yes"  indicates  that  statistical  or  probabilistic 
analysis  is  performed  on  the  circuit.  Statistical  analysis  vs 
deterministic  analysis  Is  a  tradeoff  between  speed  and  accuracy. 

ENHANCE  ATO?:  All  testability  analysis  will  enhance  test  program 
generation,  however,  a  "NO”  here  Indicates  that  the  program  Is  not 
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closely  coupled  to  the  ATQ  process  and  It  does  not  have  a  direct 
Impact  on  tests  generated.  Tools  that  do  significantly  enhance  the 
ATQ  process  were  either  labeled  with  the  word  "VECTORS”  or 
"STRTQY".  This  was  done  to  distinguish  between  ATG's  that 
produce  a  myriad  of  digital  test  vectors  and  test  generation  that 
produces  an  overall  test  strategy.  A  test  strategy  may  or  may  not 
include  digital  test  vectors. 

CHNQ/  RE-ANA?:  A  "yes"  Indicates  that  one  Is  able  to  run  the 
analysis  and  detect  the  areas  that  require  changes  and  then  re-run 
the  analysis  while  remaining  within  the  program. 
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ACRONYM 

APPUCATION 

LEVEL  OF 
ANALYSIS 

‘T18TPNT 

ANAUkic 

‘STATISTIC 

ANALYSIS? 

‘ENHANCE 

‘CHNQ/ 

RB'ANA 

CART 

VLSI/PCB/ 

QATE 

YES 

NO 

NO 

NO 

CAMELOT 

VLSI 

GATE 

NO 

NO 

NO 

NO 

COMET 

VLSI 

QATE 

YES 

NO 

NO 

YES 

COP 

VLSI 

GATE 

NO 

NO 

VECTORS 

NO 

COPTR 

VLSI/PCB 

GATE 

NO 

NO 

VECTORS 

NO 

OTA 

VLSI/PCB 

QATE/REQ/ 

MACRO 

YES 

NO 

NO 

YES 

FACE 

VLSI 

TRN8TR/ 

GATE/BLOCK 

NO 

YES 

NO 

NO 

HECTOR 

VLSI 

QATE 

NO 

NO 

VECTORS 

YES 

Hn'AP 

VLSI 

QATE 

NO 

NO 

NO 

NO 

IDSSAAfSTA 

PCB/8UBSYS 

SYSTEM 

COMPONENT/ 

DEPENDENCY 

MODELING 

YES 

NO 

STRTQY 

NO 

IHAP 

VLSI 

QATE 

NO 

NO 

NO 

YES 

PROTEST 

VI  .SI 

TRN8TFV 

QATE 

NO 

YES 

VECTORS 

YES 

STAMP 

ALL  L'^.VELS 

COMPONENT/ 

DEPENDENCY 

MODELING 

YES 

NO 

STRATEGY 

NO 

SCOAP 

VLSI 

QATE 

YES 

NO 

NO 

NO 

TESTABILfTY 

CHECKLIST 

PCB^UBSYS 

COMPONENT 

NO 

NO 

NO 

NO 

THESEUS 

VLSI/PCB 

THN8TR/ 

QATE 

NO 

NO 

VECTORS 

YES 

TMEA8 

VLSI/PCB 

REGISTER 

YES 

NO 

VECTORS 

NO 

VICTOR 

VLSI 

QATE 

YES 

NO 

NO 

NO 

Sm  pravloiMi  page  for  axplanatlon  of  thaia  oatagorlaa. 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


4.1.1  CART 


NAME:  CART  -  Computer-Aided  Fault  Isolation  Testability 

YEAR:  1987 

FUNCTION: 

•  Identifies  epeolflc  circuitry  which  inhibits  or  defeats  fault  detection 

•  Chooses  optimal  Input  and  output  test  points 

Estimates  maximum  possible  fault  coverage  (this  analysis  doss  not 
require  any  test  vector  generation) 

•  Identifies  feedback  loops  and  the  fewest  number  of  breakpoints 

-  Provides  an  Index  of  fault  isolation  test  program  complexity  based  on 
the  number  of  signals 

CAPACITY:  3500  gates  on  an  IBM  PC-AT  w/640  K.  Memory  requirement  for  larger 
networks  1  Mbyte  RAM  for  each  6,000  network  equivalent  gates.  Capacity  on 
Mentor  Graphics  Idea  Station  Is  100.000  gates. 

CPU  TIME:  Full  Analysis  of  3600  gate  design  on  an  IBM  PC-AT  Is  4  hours.  Run 
time  dependency  on  model  size  is  slightly  higher  than  linear.  Run  time  Inversely 
proportional  to  MIPS. 

APPLICATION;  VLSI.  PCB.  SUBSYS.  SYSTEM 

ACQUISITION  PHASE:  CONCEPT,  DEMA/AL.  PSD.  PRDCTN,  DPLYMNT 

PUBLIC  DOMAIN:  Y/N  QFE 

DESIGN  ENV;  IBM  PC-AT  and  Mentor  Graphics  Idea  Station.  It  is  written  In 
FORTRAN  77. 

CIRCUIT  DESCRIPTION:  Netllst 

USE  PREREQUISITE;  No  training  Is  required.  Device  library  must  be  created 
based  on  function  table  descriptions  of  devices.  No  special  language  has  to  be 
learned. 
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DEVELOPER:  ATAC,  Mountain  View,  CA 
COMMENTS: 


-  Identifies  specific  circuitry  which  Inhibits  or  defeats  fault  detection 
>  Can  generate  reports  In  terms  of  color-ended  schematics 

-  Able  to  process  bl-directlonal  signals 
REFERENCES: 

1.  ATAC 

ATTN:  Brad  Ashmore 
1200  Villa  Street 
Mountain  View,  CA  94041 
(416)965-8801 

2.  Naval  Ocean  Systems  Center,  "Testability  Analysis  Tools  On  A 
Military  System",  Technical  Report,  September,  1987. 

3.  Navy  Point  of  Contact 
Naval  Ocean  Systems  Center 
Code  936(B) 

San  Diego,  CA  92162-5000 
(619)  553-3261 
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4.1.2  CAMELOT 

NAME;  CAMELOT  -  Comput«r  Aldsd  Measure  for  Logic  Testability 
YEAR:  1980 

FUNCTION:  Assigns  CY  and  OY  values  for  every  node  In  the  circuit  and 
calculates  Testability.  Unlike  SCOAP,  CAMELOT  can  compute  Testability  around 
feedback  paths  or  reconvergent  circuits. 

CAPACITY; 

CPU  TIME: 

APPLICATION:  ££fi  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  ^  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/^l  see  HITAP  (Tool  No.  4.1.9) 

DESIGN  ENV:  The  first  draft  was  written  In  Pascal  and  used  a  subset  of  a  circuit 
Image  written  for  the  TEQAS  logic  simulator,  but  Is  not  restricted  to  this  form  of 
Input. 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE:  One  must  read  In  and  check  circuit  connectivity  description. 
Also  CY  and  OY  transfer  factors,  CTF  &  OTF,  must  first  be  computed  for  each 
node. 

DEVELOPER;  Cirrus  Computers,  UK,  for  the  British  Post  Office 

COMMENTS:  The  ultimate  measure  of  Testability  Is  the  total  cost  of  producing 
and  evaluating  a  test  program.  CAMELOT  provides  a  quick,  early  evaluation  to 
guard  against  coat  overruns. 

Provides  Interactive  design  for  Testability. 

•  For  reconvergent  paths  of  unequal  length,  CAMELOT  selects  the 
shortest  path. 

•  For  reconvergent  paths  of  equal  length,  CAMELOT  computes  the  OY 
for  both  paths  and  retains  the  higher  value. 
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•  A  simple  measure  of  Testability,  for  each  line  Is  obtained  In 
CAMELOTas: 

Testablllty(llne)  -  CY(line)  *  OY(line) 

where  0<Testablllty<1  for  0<CY<1  and  0<OY<1. 

•  The  overall  Testability  of  the  oiroult  Is  computed  as  the  arithmetic 
mean  of  the  individual  line's  Testability: 

Testablllty(clrcult) «  Total  Sum  of  All  TY(llnes) 

No.  of  lines 

'  CAMELOT  may  be  used  in  a  test  generation  strategy  because  of  the 
path  sensitizing  approach  included  In  the  CAMELOT  algorithm. 

•  Because  CAMELOT  does  not  provide  for  automatic  re*analysls  of  the 
oiroult,  obtaining  a  circuit  design  optimized  for  testing  can  be  an 
exhaustive  process. 

•  For  very  large  scale  oirouits  the  computations  necessary  to  derive 
CTF  and  OTF  become  uneconomical. 

REFERENCES: 

1.  Bennetts,  R.G.,  et  al,  "CAMELOT,  A  Computer*Alded  Measure  For 
Logic  Testability,”  IEEE  International  Conference  on  Computers  and 
CIroults,  1980,  p  1162*1  les. 

2.  Bennetts,  R.Q.,  "Design  Of  Testable  Logic  CIroults*  Addison  Wesley, 
Reading,  MA. 

3.  Also  see  HITAP 
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4.1.3  COMET 

NAME;  COMET  •  Controllability  and  Obsarvablllty  Meesurament  for 
Testability 

YEAR;  1982 
FUNCTION; 


•  Measure  Testability  from  controllability  (Cy)  and  observability  (Oy) 
measurements  for  each  node,  as  well  as  an  overall  Teatablllty 
statistic. 

•  A  graphic  statistics  option  Is  available.  The  statistical  analysis  of  the 
circuit  Teetablllty  measuree,  such  as  the  combinational  CY/OY  mean 
and  standard  deviation,  are  provided. 

•  Re-desIgn  and  re>analysls  wHhin  COMET  capability. 

•  Automated  test  point  and  toglo  Inserters  available. 

•  A  measure  of  ease  of  Initialising  the  circuit  for  test  Is  one  of  COMET'S 
outputs. 

CAPACITY;  N/A 
CPU  TIME;  N/A 

APPLICATION;  Vl^  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSfi  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/N 

DESIGN  ENV;  Part  of  Highland  Design  CAD  System;  VAX  1 1/7B0 
CIRCUIT  DESCRIPTION;  McLDL 
USE  PREREQUISITE; 

DEVELOPER;  United  Technologies  Microelectronics  Center 
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COMMENTS; 

•  B«8«d  on  SCOAP  (goto  lovol) 

•  Doslgnors  can  axparlmant  with  diffarant  mathoda  without  having  to 
ohanga  tha  cirouit  daaortption  or  raoomplla. 

•  COMET  can  handia  oiroult  oharaotarlatloa  auoh  aa  gata  Inputa  tiad 
diraotly  to  powar  and  ground,  bidtractlonal  signals,  and  thraa  state 

buses. 

•  Tha  user  enters  a  single  line  of  ooda  to  describe,  for  example,  an 
Artthmatio  Logic  Unit  (ALU). 

•  Pan-out  nodes  are  listed  and  their  OY's  are  given  as  the  minimum  of 
the  fan-out  branch  OYs.  This  Information  la  Important  when  running 
fault  simulation  to  determine  the  fastest  propagation  path. 

•  COMET  Is  not  used  to  predict  test  patterns  or  to  aid  In  fault 
simulation. 

REFERENCES; 

-  Berg,  W.L..  Haas,  R.D.,  *COMET;  A  Testability  Analysis  And  Design 
Modification  PaoHags,"  IEEE  International  Test  Conference,  1982 
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4.1.4  COP 

NAME;  COP  •  Controllability  and  Obaarvabllity  Program 

YEAR:  1984 

FUNCTION: 

•  Eitimata  fault  covaraga  whan  paaudo  random  pattami  ara  appllad 
■  Hauriatlea  oarry  ovar  for  ATP  ganaratlon. 

•  Taatablllty  aasaaamant  with  or  without  tast  pattarna. 

•  I/O  with  Taatablllty  algnaturaa  can  aid  In  daaign  varlfication. 

CAPACITY: 

CPU  TIME;  Ordar  of  magnituda  faatar  than  traditional  fault  almulatora. 

APPLICATION;  ^  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  FSfi  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/fci 

DESIGN  ENV;  IBM 

CIRCUIT  DESCRIPTION:  Nautral  flla 

USE  PREREQUISITE;  Lavallza  and  rawrita  uaing  only  ona  typa  natllat; 
racommand  uaing  a  program  for  thia  taaK 

DEVELOPER:  Ball  Northam  Rasaaroh 
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COMMENTS; 

•  lists  Booltsn  sigsbrs  to  dstsrmlns  fsult  dstoctlon. 

•  Dots  not  dttsot  rtdundantly  mtsktd  fsults. 

•  Fault  simulation  mathod. 

•  Crttloal  dtlay  path  tract  capability. 

•  Qata  Itvtl  rtprtsv>ntati<m. 

>•  Tht  combinationai  circuitry  It  partitlonsd  Into  sats  of  ovtrlapping 
structural  oonts  which  also  htips  to  snhanes  ths  ATFQ  proctss  and 
Iht  crttloal  dtlay  path  tracing  aigortthm. 

-  Similar  to  TE8T8CREEN  (not  dtsortbtd  In  this  documant). 

>  Ustd  by  Ttxaa  Inst. 

REFERENCES: 

•  Brgita,  F.,  Pownall,  P.,  Hum,  R.,  •  Applications  Of  Tastablllty 
Analysis:  From  ATPQ  To  Critical  Dtlay  Path  Tracing,"  1984  IEEE 
Intamational  Tast  Conftrtnot. 


C-115 


DESIGN  ALTTOMATION  TOOLS 


APPENDIX  C 


4.1.8  COPTR 

NAME:  COPTR  •  Controllability  >  Obsarvabllity  •  Pradlotablllty  •  Taatablllty 

Raport 

YEAR:  1982 
FUNCTION: 

•  CY,  OY,  And  Taatablllty  analyalt  for  aaoh  noda  aa  wall  at  for  tha 
antira  circuit. 

•  Cloaaly  oouplad  wHh  ATQ. 

>  It  points  out  ohangaa  that  would  maka  a  circuit  taatabla. 

CAPACITY:  (Exampla)  6.894  signals 

CPU  TIME:  Tha  abova  axampla  was  oompilad  In  2  min,  linkad  In  10  min,  tha  fault 
ganaratlon  took  3  min,  and  tha  COPTR  computa^n  tima  was  20  min. 

APPLICATION:  yiJSl  8UB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  £312  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  iC/N  (PRTY) 

DESIGN  ENV:  Tha  TEQAS  •  6  softwara  family  for  daslgn  and  fast  simulation; 
CALMA  workstations;  32  BIT  Apollo  workstation;  suparvisad  by  Taskmastar. 

CIRCUIT  DESCRIPTION:  TEQAS  Dascriptlon  Languaga  (TDL) 

USE  PREREQUISITE:  Coda  natwork  dascriptlon  In  TDL,  complla  and  link.  No  tast 
pattam  or  simulation  Is  raquirad. 

DEVELOPER:  CALMA  Company 
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COMMENTS; 


•  Many  CALMA  manus  anabla  variations  of  COPTR  printout. 

-  COPTR  Is  hiararohloal  with  a  good  model  library. 

•  Use  with  TCAT,  CALMA'a  fault  simulator  and  ATPQ. 

REFERENCES: 

1.  Kirkland,  T.,  Flores,  V., "Software  Checks  Testability  and  Generates 
Tests  of  VLSI  Design," ,"  Eleotronlos  Mag.,  March  10, 1083. 

2.  CALMA  Company; 

Attn:  Thomas  Poos 
Mllpatas,  Ca.  05035  •  7480 
(408)  434-4870 

3.  Naval  Ocean  Systems  Center,  J.C.  Bussert,  Testability  Measures  On 
a  State-of-the-Art  Circuit,"  Technical  Document  835,  Feb,  1086 
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4.1.6  DTA 

NAME:  DTA  •  DAISY  Ttstabliity  Analyzer 
FUNCTION: 

•  Computes  six  CY  and  OY  values  for  each  node. 

•  Evaluates  Boolean  expressions,  ROMS,  RAMS,  and  PLAs. 

•  Manual  or  automatic  test  point  Insertion. 

•  Allows  for  re-evaluatlon  In  software  mode. 

CAPACITY:  (Example)  122,1 10  gate  equivalent  circuit 
CPU  TIME:  8  MIPS;  1 1  min  for  above  example. 

APPLICATION:  ytSl  ££B  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  ^  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?:  Y/N  (PRTY) 

DESIGN  ENV:  Daisy  Logician  Workstation,  Intel  802B6  based.  Used  with 
QATEMASTER,  CHIPMASTER,  BOARDMASTER,  and  MEQAQATEMASTER. 
Written  In  PUM  with  12,000  lines  of  code. 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE:  Validation  by  Daisy  Logic  Simulator  ensures  the  design  is 
ready  for  DTA. 

DEVELOPER:  Daisy  Systems  Corporation 
COMMENTS: 

>  DTA  is  event  directed  and  compiler  driven,  therefore  requires  no 
library  and  can  process  macro  cells. 

-  DTA  Is  SCOAP  based. 
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REFERENCES: 

1.  Wang,  L.T.,  Law,  E.,  "An  Enhanced  Daisy  Teatability  Analyzer 
(DTA),"  AUTOTESTCON,  1986. 

2.  Daley  Systems  Corp, 

Attn:  Mark  Fucelo 
700  MIddlefleld  Road 
Mountain  View,  Ca.  94039 
(416)960-7168 

3.  Naval  Ocean  Systems  Center  ."Testability  Analysis  Tools  On  A 
Military  System ",  Technical  Report,  September,  1987. 
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4.1.7  FACE 

NAME:  FACE  -  Fault  Coverage  Estimation 

YEAR:  1906 

FUNCTION: 

•  Statistical  fault  analysis. 

•  Applicable  to  mixed  levels;  MOS  transistor  level,  gate  level,  and 
combinational  functional  block  level. 

•  Its  logic  simulator  deploys  both  event  driven  and  circuit  leveling 
techniques. 

CAPACITY:  Information  not  available. 

CPU  TIME:  Information  not  available. 

APPLICATION:  ^  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  F§D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N  UNIV 

DESIGN  ENV:  Unknown 

CIRCUIT  DESCRIPTION:  See  above. 

USE  PREREQUISITE:  Information  not  available. 

DEVELOPER:  University  of  California;  Berkeley,  CA 
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COMMENTS:  The  ability  of  FACE  to  process  both  gate  level  and  transistor  level  Is 
particularly  useful  when  designing  with  CMOS  technology.  Stuck  open  CMOS 
transistors  cause  the  combinational  logic  they  are  part  of  to  exhibit  sequential 
behavior,  which  Is  an  order  of  magnitude  more  difficult  to  analyze. 

One  Is  able  to  process  Testability  analysis  while  the  design  is  only  described  in 
functional  blocks. 

REFERENCES: 

•  Ma,  H.K.,  SanglovannI  -  Vincentelll,  A.L.,  "Mixed  Level  Fault 
Coverage  Estimation,”  IEEE  Design  Automation  Conference,  1 986 
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4.1.8  HECTOR 

NAME:  HECTOR  •  Heuristic  Controllability  And  Observability  Analysis 

YEAR:  1984 

FUNCTION: 

•  Creates  a  weighted  AND/OR  graph  based  upon  the  circuit 
description. 

•  Calculates  CY  and  OY  (identical  to  SCOAP)  and  Testability 
measures. 

-  CY  and  OY  measures  are  assigned  to  the  hyperarcs  connecting  the 
parent  node  with  a  set  of  successor  nodes. 

* 

•  Hyperarcs  are  ordered  according  to  CY  and  OY  measures. 

•  Creates  a  tree  search  data  base  to  run  ATWIQ,  Ref[21&[4],  and  EDIT, 
Ref[1]. 

•  Provides  guidance  at  each  decision  node  for  ATWIQ. 

-  Provides  guidance  on  how  to  select  flip-flops  to  be  Included  Into  an 
incomplete  scan  path. 

CAPACITY:  10,000  nodes. 

CPU  TIME:  Example  circuit  requires  371  sec  on  VAX  1 1/780;  for  other  benchmark 
circuits,  see  Ref.  [3], 

APPLICATION:  VLSI  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  F§D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N 

DESIGN  ENV:  Written  in  C  with  UNIX;  part  of  IDAS:  Integrated  Design  for 
testability  and  Automatic  TPG  System.  See  COMMENTS  and  Ref  [1]. 

CIRCUIT  DESCRIPTION;  CADAT  circuit  file  Input  description. 

USE  PREREQUISITE:  Keyboard  command  transforms  circuit  description  from 
Daisy  Logician  database  to  CADAT  to  run  IDAS. 


C-122 


I 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


DEVELOPER;  Siemens  Corporate  Research  and  Support,  Princeton,  NJ. 

COMMENTS:  The  IDAS  design  system  consists  of  the  following; 

CADAT  •  a  fault  simulator 

HECTOR  •  testability  analyzer 

PRETEST  -  predicts  the  cost  of  an  ATQ  run.  See  Ref[6]. 

EDIT  •  A  set  of  tools  to  evaluate,  display  and  Improve  Testability 
(e.g.,  to  automatically  Include  an  Incomplete  scan  path  Into  a  given 
circuit). 

ATWIQ  -  Automatic  TPQ  With  Inherent  Guidance  for  combinational 
and  sequential  circuits.  See  RefI2]&[4]. 

The  IDAS  system  was  developed  for  research  purposes  only,  many  of  Its  features 
are  used  in  SOCRATES  (3.2.2.4).  an  ATPQ,  see  Ref.  [?]• 


REFERENCES: 

1 .  Trlshler,  E..  "An  Integrated  Design  for  Testability  and  Automatic  Test 
Pattern  Generation  System:  An  Overview,”  Proc.  21st  Design 
Automation  Conference  1984,  pp.  209*215. 

2.  T  <tchler,  E.,  "ATWIG,  An  Automatic  Test  Pattern  Generator  With 
Inherent  Guidance,”  Proc.  1964  IEEE  Int.  Test  Conf.,  pp.  80*87. 

3.  TrIsohKjr,  E..  Schulz,  M.,  "Applications  to  Testability  Analysis  to  ATQ: 
Methods  and  Experimental  Results”,  Proc.  1985  IEEE  Int.  Symp.  on 
Circuits  and  Systems,  PP.  601*804. 

4.  Trlschler,  E.,  "Guided  Inconsistent  Path  Sensitization:  Method  and 
Experimental  Results”,  Proc.  1985  IEEE  int.  Test  Conf.,  ppl  79*66. 

5.  Trlschler,  E.,  "A  Methodology  for  Statistical  Evaluation  of  Estimated 
and  Real  Testability  Measures,”  Siemens  Forsch.  -  u.  Entwiokl.*Ber., 
Vol.  16,  No.  1, 1987,  pp.1*6. 

6.  Trlschler,  E.,  "Incomplete  Scan  Path  with  an  Automatic  Test  Pattern 
Generation  Methodology,”  Proc.  1980  IEEE  Test  Conf.,  pp.  153-162. 

7.  Schulz,  M.H.,  E.  Trlschler,  and  T.M.  Sarlert,  "SOCRATES:  A  Highly 
Efficient  Automatic  Test  Pattern  Generation  System,”  IEEE  ITC  1987, 

pp.  1016-1026 
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4.1.0  HITAP 

NAME;  HTTAP  ^  Hl-Tdstablllty  Analysis  Program 
YEAR:  1986 

FUNCTION;  HITAP  Is  a  tastablllty  analysis  program  for  gat#  array  and  standard 
cell  designs.  HITAP  Is  compatible  with  QenRad’s  HILO  Universal  Logic  Simulation 
System.  It  allows  the  design  engineer  to  Integrate  testability  Into  the  design 
process.  With  HITAP,  areas  that  are  difficult  to  teat  are  revealed  during,  rather 
than  after,  the  design  process.  HITAP  provides  the  user  with  a  relative  figure  of 
merit  for  each  circuit  node.  The  figures  of  merit  are  expressed  In  terms  of 
observability  (the  ability  to  observe  a  node  at  a  primary  output)  and  controllability 
(the  ability  to  control  the  node  from  a  primary  input).  HITAP  calculates  a  testability 
figure  of  merit  for  each  Item  analyzed,  as  the  product  of  the  observability  and 
controllability  factors,  These  factors  then  provide  a  relative  measure  of  the 
testability  of  the  design, 

CAPACITY: 

CPU  TIME: 

APPLICATION:  y^Si  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  fSE  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  1/N  (PRTY) 

DESIGN  ENV:  DEC  32  bit  machine;  used  In  conjunction  with  HILO,  HIPOST, 
HICHIP,  HITEST;  written  In  Pascal. 

CIRCUIT  DESCRIPTION;  Hardware  Description  Language  (HDL) 

USE  PREREQUISITE:  Requires  netllst  In  HILO  format,  HDL. 

DEVELOPER: GenRod 
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COMMENTS:  HITAP  first  finds  CY,  thsn  OY,  thsn  Testability. 

REFERENCES; 

GenRad  Inc. 

Attn:  Michael  Busch 
37  Main  St. 

Bolton,  Maas  01740 
(508)  779-6271 
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4.1.10  ID88-W8TA 

NAME;  ID88  •  W8TA  •  Weapon  Syttem  TtetabllHy  Anaiyztr 

YEAR; 

FUNCTION;  Tho  WSTA  providot  tho  following  tostablllty  analyzer  oapabilltlee; 

•  Controllablllty/Obtervablllty  oaloutatlons  tor  each  teat  point  or  I/O 
contained  In  the  UUT. 

-  Teat  point  utilization  data.  A  measure  of  how  often  a  teat  la  used  in  a 
teat  strategy. 

•  Teat  point  critioality.  A  measure  relating  the  teat  point  to  the  criticality 
of  the  circuitry  Involved. 

•  Provide  to  the  teat  designer  a  prloHtlzed  Hat  of  teat  points  which  must 
be  monitored  to  detect  the  presence  or  absence  of  a  fault  in  the 
weapon  system  under  test. 


Refer  to  the  Tools  That  Aid  Testabllity/Dlagnostio  Prediction  for  more 
details  and  mors  capabilities  of  the  IDSS/WSTA  tool  (4.2. 1.4). 
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4.1.11  ITTAP 

NAME:  ITTAP  •  Intfraotlv*  Testability  Analysis  Program 

YEAR:  1982 

FUNCTION: 

•  Tastablllty  analysis  program. 

•  Maaauras  art  provided  for  2  groups:  diffioulty  to  control  and  obsarva, 
and  test  length. 

•  Contains  standard  logic  alamants  aa  primitives  within  the  library  as 
well  as  the  ability  to  define  CY  and  OY  of  any  block  of  logic. 

•  Interactive, 

CAPACITY: 

CPU  TIME;  It  uses  a  selective  trace  algorithm  which  saves  90  •  98%  CPU  time 
compared  to  trying  to  evaluate  every  node  for  every  test  vector. 

APPLICATION;  YLfil  PCB  8UBSY8  8Y8TEM 

ACQUISITION  PHASE:  CONCEPT  DEMA^AL  ESC  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/£i 

DESIGN  ENV;  The  Prime  760  waa  used  In  the  example. 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE;  Describe  circuit  as  Interconnections  of  standard  cell 
elements  found  In  library  or  Fortran  subroutine. 

DEVELOPER;  ITT-LSI  Technology  Center 
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COMMENTS: 

•  An  ord«r  of  magnHudo  run  timo  Improvomont  ovtr  8COAP . 

•  Varloui  Intaractlva  oommandt  for  ataaatlng  Taatablllty  ara  avallabla. 
REFERENCES: 

•  Goal.  C.K.,  MoDarmott,  R.M.,  "An  Intarativa  Taatablllty  Analyala 
Program  •  mrAP,"  IEEE  Daalgn  Automation  Confaranca  1982 
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4.1.12  PROUST 

NAME:  PROTEST  •  Probabllittio  Taitablllty  Analytli 

YEAR:  1985 

PUNOTION: 

•  Using  ilgntl  probabllltlsi  aa  Input,  tha  program  will  output  tha 
probability  a  fault  will  ba  dataetad. 

•  Datarmlnaa  tha  raquirad  taat  langth  to  obtain  apaolflad  fault  oovaraga. 
CAPACITY: 

CPU  TIME:  (Exampla)  26,460  translators  with  32,000  taat  pattarns  took  23 
•aoonds  of  CPU  tima.  To  optimiza  to  1,778  taat  pattarns  took  2,181  aaeonda  of 
CPU  tIma. 

APPLICATION:  PCB  8UB8Y8  8Y8TEM 

ACQUISITION  PHASE:  CONCEPT  OEM/VAL  ESfi  PRDOTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N 

DESIGN  ENV:  Oarlaruhar  Digital  DaaIgn  Syatam  (CADDY)  (Univaralty  of 
Carlaruhar,  Fad  Rap  of  Garmany);  writtan  In  Pascal.  Tha  axampla  was  run  on  a 
Slamans  7561  oomputar. 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE:  A  daaorlptlon  of  tha  combinational  olrouH. 

DEVELOPER:  Unlv  of  Karlsruha.  Germany 
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COMMENTS: 

•  Wh«n  using  BILBO,  PROTEST  dstsrminss  tsst  Isngth. 

•  Whsn  using  NLFSR,  PROTEST  dstsrmlnss  optimal  Input  signal 
probsbilltiss. 

•  It  rtduoss  computing  timo  of  ATPQs  by  providing  optimizsd  psttom 

sots. 

REFERENCES: 

•  Hons-Joaohim  Wundoriioh.  "PROTEST:  A  Tool  For  Probablllstlo 
Tostsbillty  Analysis,”  IEEE  Doslgn  Automation  Conforonoo  1065. 
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4.1.13  8COAP 

NAME:  8C0AP  •  Sandia  Controllablitty/Obaarvablllty  Analyala  Program 

YEAR:  1980 

FUNCTION: 

•  Caloulataa  alx  funotlona  that  oharaotariza  CY  &  OY  propartlas  of 
digital  oirouita. 

-  IdarttKIaa  poor  Taatablllty  nodaa. 

•  MaKaa  taat  point  raoommai  tiiauona. 

•  Evaluataa  daaign  modlfloationa. 

CAPACITY:  (In  1080)  Mora  than  10,000  standard  oalla  or  mora. 

CPU  TIME:  Tha  worst  oasa  atruotura  of  a  olrouH  with  250  oalla  took  91  aaoonda. 
APPLICATION:  ^LSl  PCB  SUB8YS  SYSTEM 
ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESC  PRDCTN  OPLYMNT 
PUBLIC  DOMAIN?:  ^  (UNIV) 

DESIGN  ENV:  A  DEC  SYS  10  Computar  waa  uaad  In  tha  axampla.  It  Is  writtan  In 
atruoturad  FORTRAN  and  is  raasonably  portabla.  Tha  aouroa  coda  -  3,000  llnaa. 

CIRCUIT  DESCRIPTION:  No  apaclal  languaga. 

USE  PREREQUISITE:  Tha  circuit  must  ba  daaoribad  aa  a  natllat  of  alamanta 
oontalnad  In  tha  library. 

DEVELOPER;  Sandia  Laboratoriaa 
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COWMENTSi 

•  SCOAP  oontitts  of  6  modulot  porforming  th«  following  functions; 
control,  proprootss,  tnnslatlon.  calculation,  sorting,  and  graphing 

>  SCOAP  has  widaspraad  popularity.  Othar  testability  analysis  tools 
are  either  based  on  It  or  compare  themselves  to  It. 

•  Further  analysis  by  the  designer  Is  often  required  after  SCOAP  has 
processed  suoh  oiroult  elements  as  reoonvergent  fan-outa,  redundant 
nodes,  power  and  ground  lines,  tied  nodea,  and  bidirectional  devices. 

-  Users  have  sought  to  Improve  SCOAP  by  Including  the  ability  to 
provide  design  modlfloatlons,  reduce  test  generation  coats.  Increase 
fault  coverage.  Identify  redundancy,  etc. 

REFERENCES: 

•  Qoldstein,  L.H.,  Thigpert,  E.L,  *SCOAP:  Soandia  Controllability  And 
Observability  Analysis  Program,*  IEEE  DAC,  1080. 
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4.1.14  STAMP 

NAME;  STAMP  -  System  Testability  And  Maintenance  Program 
YEAR:  1980 

FUNCTION;  STAMP  provides  the  following  testability  analyzer  capabilities: 

•  Testability  Improvement  recommendations. 

•  Test  point  evaluation. 

•  BIT  effeotiveneas. 

Refer  to  the  Tools  That  Aid  Testablllty/Diagnostio  Prediction  section  for  more 
details  and  more  capabilities  of  STAMP  (4.2. 1.7). 
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4.1 .1 5  TMtablllty  Checklist 
NAME;  Tsstsblllty  Chseklltt 
YEAR:  1979 

FUNCTION:  A  quick  and  Insxpsnaivs  way  of  evaluating  testability  by  requiring  the 
user  to  review  his  design  by  answering  a  list  of  generic  questions  and  estimate  a 
score  of  how  well  his  design  for  testability  is.  The  two  reference  below  are 
provided  as  sources  for  examples  of  Testability  Checklist. 

CAPACITY:  N/A 

CPU  TIME;  N/A 

APPLICATION:  VLSI  ££B  8UB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  Egg  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  (QFE) 

DESIGN  ENV;  Pencil,  paper,  and  calculator. 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE;  Ample  definition  or  description  of  the  system  requiring 
testability. 

DEVELOPER;  MIL-STD-2ie6/RADC  -TR  -79  -327 

COMMENTS:  Computers  are  potentially  able  to  make  the  checklist  method  more 
powerful. 

Extensive  engineering  analysis  Is  still  required  after  using  the  checklist  approach. 

The  Testability  Checklist  of  Ref[2]  has  fixed  Hems  of  weighting  and  applies  only  to 
digital  boards,  whereas  the  one  provided  In  Ref[1]  allows  sublective  treating  of 
Items  and  weighting  values  and  applies  to  dlgltal^nalog  circuitry  from  module  to 
system  level  design.  As  of  the  publication  date  of  this  document,  both  tools  were 
under  revision. 

•  The  Testability  Checl^llsts  of  both  references  are  "free*  and  can  be 
utilized  well  In  selective  applications. 


C-134 


DESIGN  ALTTOMATION  TOOLS 


APPENDIX  C 


REFERENCES; 

1.  MIL'STD  2165  Appendix  B;  ”Testablll1y  Program  for  Systems  and 
Equipments,*  Publications  &  Forms  Center 

Available  through: 

Attn:  NPFC  1032 
5801  T-ibor  Ave. 

Philadelphia,  Pa.  19120 

2.  RADC  •  TR  •  79 ' 327;  *An  Objective  Printed  Circuit  Board  Testability 
Design  Quids  And  Rating  System”  January,  1 980. 

Available  through: 

DTIC 

Report  AD  082329 
Cameron  Station 
Alexandria,  VA  22304*61 45 
(202)  274-7633 

3.  Naval  Ocean  Systems  Center,  *Testablllty  Analysis  Tools  on  a 
Military  System,"  Technical  Report,  September,  1987. 
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4.1.16  THESEUS 

NAME:  THESEUS  •  ATQ  WHh  Inherent  iMtftbillty  Analyzvr 
YEAR:  1986 

FUNCTION:  An  ATQ  system  capable  of  high  fault  coverage  for  complex 
sequential  circuits  without  need  to  change  design  for  Testability.  There  is  an 
optional  Interactive  Testability  analyzer. 

THESEUS  provides  the  following  testability  analyzer  capabilities: 

•  List  of  zero,  one,  and  tri-state  CY  for  each  node  In  the  circuit,  sorted 
by  node  or  value 

•  Histogram  displaying  nodal  CY 

•  List  of  nodes  that  cannot  be  controlled 

•  List  of  sources  of  un-CY 

•  List  of  feedback  loops  that  cannot  be  i  iitlallzed 

Refer  to  the  Tools  That  Aid  Testablllty/Dlagnostic  Prediction  (ATQ  or  Fault 
Simulation)  section  for  more  details  and  more  capabilities  of  THESEUS  (3.3.2.5). 
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4.1.17  TMEA8 

NAME;  TMEAS  •  Testability  Measurement 
YEAR:  1976 

FUNCTION;  Measures  CY  &  OY  and  thus  derives  Testability  of  each  node  as  well 
as  the  total  circuit. 

Identifies  poor  Testability  locations. 

Provides  test  point  selection. 

Aids  test  generation. 

CAPACITY;  (Example)  PCB  with  20  •  70  ICs  of  SSI  &  LSI  complexity. 

CPU  TIME;  (Example)  400  signal  paths  took  3  seconds  to  process. 

APPLICATION;  ^LSl  ESS  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  fSB  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/Ii 

DESIGN  ENV:  (Example)  IBM  TSS/370;  Amdahl  470  V/7 
CIRCUIT  DESCRIPTION;  LSL  Local 

USE  PREREQUISITE;  Translate  circuit  description  of  LSL  Local  Into  a  Testability 
model. 

DEVELOPER:  AT&T  Bell  Labs 

COMMENTS:  It  modols  at  the  register  transfer  level. 

The  algorithm  can  be  gleaned  from  the  two  reference  articles  and  home  grown 
Implemented. 
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REFERENCES: 

1 .  J.  E.  St«ph«n8on  and  J.  Qraaon,  "A  Taatablllty  Maaaura  For  Register 
Transfer  Level  Digital  Clroulta,"  Prooeedinge  of  1976  International 
Symposium  on  Fault  Tolerant  Computing,  June  1976,  pp.  101-107. 

2.  John  Qraaon,  TMEAS,  A  Testability  Measurement  Program,”  IEEE 
DAC  1979 

3.  AT&T  Bell  Laboratories 
Attn:  John  Qrason 
IL417 

Holmdel,  New  Jersey  07733 
(201)949-3000.ext-3086 
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4.1.18  VICTOR 

NAME:  VICTOR  -  VLSI  Identifier  Of  Controllability,  Teatabillty,  Observability, 

And  Redundancy 

YEAR:  1982 
FUNCTION:  See  title. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  ^  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  ESQ  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/£4 

DESIGN  ENV:  VICTOR  algorithm  was  Implemented  with  3500  lines  of  ANSI 
FORTRAN  77 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE: 

DEVELOPER:  Electronics  Research  Lab,  University  of  California,  at  Berkeley. 
COMMENTS; 

REFERENCES: 

-  Ratlu,  I.M.,  et  al,  "VICTOR:  A  Fast  VLSI  Teatabillty  Analysis 
Program,"  IEEE  International  Test  Conference,  1082. 
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4.2  DIagnoatle  EffMtlv«n«M  Tools 

Thors  ore  two  clottot  or  ostogorloo  of  tools  that  Ho  undor  tho  diagnostic 
tost  affootivonoss  tool  umbrolla:  tost  stratogy  tools  and  fault  simulation  tools.  Both 
oatogorlos  of  tools  assoss  tostablltty/dlagnostios  via  amploying  a  tost  offootivonoss 
moasuro  to  tho  assossmont  mothodology  utilizod. 

4.2.1  Toot  Stratogy  Tools 

This  soctlon  contains  softwaro  tools  avallablo  to  aid  In  tho  task  of 
prodloting/aaaossing  tho  offootivonoss  and  stratogy  of  aystom  diagnoatloa  via  a 
Tostabillty  FIguro  of  Morit  approach. 

Thors  aro  not  claims  mads  that  this  la  an  all  Inolusivo  Hat.  Thora  aro 
porhaps  dozons  of  tools  that  aro  not  Inoludod  that  porform  bottor  or  squally  as  wall 
as  somo  of  thoso  dosorlbod  hors. 

Tho  tools  aro  arrangod  In  alphabotloal  ordor. 

Tools  that  aid  In  tho  prodlotlon  of  tho  offootivonoas  of  tho  diagnostic 
capability  and  assist  In  tost  stratogy  formulation,  ilstod  In  this  soctlon.  all  havo  tho 
foltowing  foaturoo  in  common: 

•  Thay  aro  usoful  during  mors  than  ono  acquisition  phasa  and  apply  to 
mors  than  ono  lavol  of  Intogratlon. 

•  They  apply  to  a  varloty  of  hardwara  tochnologlas,  Including  analog 
and  digital  circuitry. 

•  Thay  aro  all  dodicatod  to  aaalating  in  tho  dosign  and  ovaluatlon  of 
fault  Isolation  stratoglos. 

A  summary  doscriptlon  of  tools  that  aid  In  aosossing  diagnostic 
offootivonoss  and  tost  stratogy  functions  aro  providod  In  tho  following  tablo. 
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4.2.1 .1  ACE 

NAME;  ACE  •  APT  Computational  Environmant 

APT  -  ALPHATECH  PraQram  For  Taatablllty 

YEAR:  1087  for  phaia  1  prototypa. 

FUNCTION:  Providaa  a  taat  daolalon  traa  raport. 

Providat  histograms  with  siza  and  numbar  of  ooourranoa  of  ambiguity  groups  for 
individual  oomponanta  and  for  all  componants. 

Qivas  cost  In  tarma  of  raquirad  numbar  of  taata  and  non>tarmlnal  daolalon  nodaa. 
Qlvaa  ooat  rotating  to  Taat  Program  8ata  (TPS). 

CAPACITY; 

CPU  TIME: 

APPLICATION:  yUSl  ESB  8UBSY8  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  PSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 

DESIGN  ENV;  Sun  3/100  C  WorKatatlon 
CIRCUIT  DESCRIPTION; 

USE  PREREQUISITE:  Modal  tha  ayatam  almllar  to  a  aohamatio  diagram. 
DEVELOPER:  Alphataoh  Ino. 

COMMENTS:  ACE  la  atlll  baing  davalopad. 
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REFERENCES: 

*  • 

1.  Alphtttch  Ino. 

Attn:  Robert  Tenney 

1 1 1  MIddleaex  Turr^lke 
Burlington,  Me  01803 
(617)273  3388 

2.  Navel  Ocean  Syttema  Center,  Teatabillty  Analyele  Toole  On  A  Military 
Syetem"  Technical  Report,  September,  1087. 
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4.2.1 .2  A8TIP 

NAME:  A8TEP  •  Advanotd  Syattm  Tattabllity  Evaluation  Program 
YEAR;  1986 

FUNCTION:  Ganarata  priorltizad,  faliura  rata  walghtad,  Fault  laolatlon  Group  (FIG) 
llata  (l.a.,  fault  dictionary  or  ambiguity  llata)  and  ganarata  parformanoa  pradlotlona  of 
tha  following  common  diagnoatio  taat  oharaotariatloa: 

•  Fault  Dataotlon 

•  Taat  Exaoutlon/DataotTImaa 

•  Dataotad  FauHa  laolatad 
-  BITEOvarhaad 

•  Fault  laolatlon  Raaolutlon  (maan  &  diaorata  Hat  alzaa) 

•  Taat  Coat 
CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  Efifl  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  F8D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 

DESIGN  ENV;  IBM  PC/AT 

CIRCUIT  DESCRIPTION:  ASTEP  uaaa  a  compilad  DB  III,  which  la  not  raquirad  by 

uaara. 

USE  PREREQUISITE:  Ona  muat  Input  ayatam  faliura  rata  and  taat  covaraga 
aatimataa  or  maaauramanta. 

DEVELOPER;  BITE  INC.,  Manaaaaa,  Va. 

COMMENTS;  Taat  parformanoa  can  ba  trackad  for  any  hlararchical  laval;  hardwara 
partition,  funotlonal/logloal  partition,  or  taat  partition. 
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•  Applicabit  to  all  hardwart  tachnologlaa. 

•  ASTEP  la  a  daalgn  aid.  Tht  quality  of  tha  output  la  dapandant  upon 
tha  quality  of  tha  Input. 

REFERENCES; 

1.  BITE  INC. 

Attn:  John  Cunningham 
9254  Cantar  St. 

Manaaaaa,VA  22110 
(703)361-7060 

2.  Naval  Ooaan  Syatama  Cantar.  Taatablllty  Analyala  Toola  On  A  MIIKary 
Syatam,”  Taohnioal  Raport,  Saptambar,  1967. 
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4.2.1 .3  l-CAT 

NAME;  I’CAT  •  Intslllgint  Computtr‘Ald«d  Tast 
YEAR: 1984 

FUNCTION:  Providta  taat  atratagy  raport  In  tha  form  of  a  last  and  raplaca  flow 
.  diagram  raport. 

Providat  a  Taatablllty  analyala  raport  which  Inoludas  tha  avaraga; 

-  Coat  to  diagnoaa 

•  Raplaoamant  ooat 

-  Ambiguity  group  alza 

•  Raporta  on  taat  point  affaotivanaaa. 

Providai  printouta  of  tha  following  Information  typaa: 

•  Rallablllty  Data 

•  EDIF  CAD/CAM  Nitlllt 

•  EDIF  CAD/CAM  Graphical  Schamatio 

A  tait  program  la  automatically  ganaratad  In  BASIC  or  ATLAS. 

APPLICATION:  VLSI  ESfi  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DENWAL  F3D  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  i^N  (PRTY) 

DESIGN  ENV;  Maointoah  Plua  PC;  Apollo  and  Sun  workatatlon  compatibility  In 
davalopmant. 

CIRCUIT  DESCRIPTION;  Draw  box  with  Mao  Draw  than  click  In  Information  with 
mouaa. 

USE  PREREQUISITE:  Entar  Information  auch  aa  : 

•  voltaga  or  currant  valuaa 

•  axpart  rulaa  that  apply 

•  praaata  auch  aa  awitch  aattingo 
-  fallura  rataa 

DEVELOPER:  Automatad  Raaaoning  Corp. 
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COMMENTS;  l-CAT  seems  to  have  proven  itself  to  be  a  suocessful  Al  application. 

•  l-CAT  formally  called  IN-ATE. 

REFERENCES; 

1.  Automated  Reasoning  Corp. 

Attn;  Richard  Cantona 

290  W.  12th  St.  Suite  1-D 
New  York,  NY  10014 
(212)  206-6331 

2.  Naval  Ocean  Systems  Center,  Testability  Analysis  Tools  On  A  Military 
System,*  Technical  Report,  September,  1987. 
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4.2.1 .4  IDSS-WSTA 

NAME:  IDS8  •  W8TA  -  Weapon  System  Testability  Analyzer 
YEAR;  1989 

FUNCTION:  The  WSTA  provides  the  following  capabilities: 

Grade  the  testability  of  a  weapon  system  with  both  static  and  dynamic  TFOMs  and 
make  recommendations  for  Improvement,  ‘^he  following  are  the  static  TFOMs: 

•  Ambiguity  group  distribution. 

-  Inherent  fault  Isolation  levels. 

•  Component  Involvement  ratios.  This  Is  a  measure  of  the  number  of 
times  a  component  appears  in  any  ambiguity  group  In  relation  to  the 
total  number  of  possible  ambiguity  groups. 

•  Identification  of  alt  feedback  loops. 

TFOMs  that  are  based  on  the  actual  fault  diagnostic  strategy  are  called  dynamic 
TFOMs.  The  following  are  the  dynamic  TFOMs: 

•  Isolation  penalties  (MTTI  and  Mean  Cost  to  Isolate). 

•  Repair  penalties  (MTTR  and  Mean  Cost  to  Repair). 

•  Replacement/Isolation  tradeoffs.  Data  used  to  determine  when  further 
testing  is  preferred  to  the  repair  of  an  ambiguity  group. 

•  Test  point  utilization  data.  A  measure  of  how  often  a  test  Is  used  In  a 
test  strategy. 

-  Test  point  criticality.  A  measure  relating  the  test  point  to  the  criticality 
of  the  circuitry  Involved. 

Generate  fault  trees  and  provide  an  optimum  test  strategy  with  additional 
reports/recommendations  for  an  Improved  test  rtrategy. 

Provide  a  dependency  model  and  test  strategy/fault  tree  for  use  during  on-line 
troubleshooting. 

Provide  to  the  hardware  designer  a  prioritized  list  of  test  points  which  must  be 
.nonitored  to  Isolate  a  fault  in  the  weapon  system  under  test. 


C-149 


DESIGN  AUTOMATION  TOaS  APPENDIX  C 


CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  P£i  8UB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  PSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  JC/N  (QFE) 

DESIGN  ENV;  WSTA  requires  alth^r  a  Sun  3/160  computar,  with  UNIX  4.2  bad 
operating  system,  or  a  Digital  Equipment  Corporation  MICRO  VAX  II,  with  a  VMS 
operating  system.  A  minimum  of  4  Mbytes  of  virtual  memory  for  the  Sun  end  4 
Mbyte8/16  Mbytes  virtual  memory  for  the  MICRO  VAX  11. 

CIRCUIT  DESCRIPTION:  EHher  VHDL  and  LSAR  or  first  order  dependencies. 

USE  PREREQUISITE: 

DEVELOPER:  Harris  Corp.  under  contract  to  6ie  US  Navy. 

COMMENTS;  WSTA  may  be  applied  to  digital,  analog,  hybrid,  and/or  electro* 
mechanical  systems.  Furthermore,  WSTA  is  not  llrnKsd  to  weapon  systems  but  also 
applies  to  space,  avionics,  and  support  design. 

The  principal  sequencing  technique  In  test  strategy  generation  Is  based  upon  the 
Tims  Efficient  Sequence  of  Tests  (TEST)  algorithm  composed  of  a  top-down  search 
that  Integrates  concepts  from  Information  theory  and  Al  techniques.  See  Ref[2]. 

The  measurable  TFOMs  provided  by  WSTA  are  consistent  with  the  operational 
scenarios  used  to  detect  and  isolate  faults  in  the  field. 

Refer  to  the  Tools  That  Aid  Testablllty/Dlagnostic  Design  section  for  detailed 
descriptions  on  the  rest  of  IDSS  tools. 

It  is  Important  to  note  that  although  WSTA  is  categorized  here  as  a  prediction  tool,  It 
is  Intended  to  be  used  during  the  design  process. 
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REFERENCES: 

1.  Franco,  JR,  and  JM  Scott,  "WSTA  The  IDSS  Weapon  System 
Testability  Analyzer,"  IEEE  AUTOTESTCON  1987. 

2.  Pattipatl,  KR,  Alexandrias,  MQ,  Deokert,  JC,  Time  Efficient  Sequencer 
of  Teats  (TEST),"  IEEE  AUTOTESTCON  1986. 

3.  Dr.  Bruce  J.  Rosenburg,  "The  Navy  Integrated  Diagnostic  Support 
System«Sy8tem  Overview,  Architecture  and  Interfaces,"  IEEE 
AUTOTESTCON  1987. 

4.  Navy  Point  of  Contact 
NAVSEA  •  Code  CEL-DS 
Washington,  DC  20362*6101 
(202)  692-2035/2036 
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4.2.1 .8  LOQMOD 

NAME:  LOQMOD  •  Logic  Model 

YEAR:  1970 

FUNCTION:  Tfctablllty  evaluatlona,  automatic  taatablllty  report  with  TFOMi,  test 
strategy  recommendations.  FI  support,  part  of  expert  support,  hard  copy  logic 
mcdel.  battle  damage  assessment,  BIT  preference,  maintainability  Information,  test 
strategies,  MTTFI,  MTTR,  and  a  validation  file  output  similar  to  FMEA. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  PCB  SUBSY8  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  OEMA/AL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  J^/N  (PRTY) 

DESIGN  ENV:  Any  mainframe  or  minicomputer  with  FORTRAN  77  compiler;  IBM 
PC  &  WICAT-150  workstation 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE;  Input  schematic  or  system  block  diagram 
DEVELOPER;  DETEX 

COMMENTS:  With  available  DETEX  training,  the  user  can  enter  and  Interpret 
results. 

LOGMOD  treats  all  signals  equally,  but  human  logic  will  weigh  certain  signal  states 
tc  have  mere  relevance  than  others. 
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REFERENCES; 

1.  DETEX  Systtms  Ino.. 

Attn;  Ralph  DtPaul 

17871  Santiago  Blvd,  Suita  221 
Villa  Park,  CA  92667 
(714)  637-9325 

2.  Naval  Ooaan  Syatams  Cantar,  Taatablllty  Analysis  Tools  On  A  Military 
Systam,,"  Tachnioal  Raport,  Saptambar,  1967. 
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4.2.1 .6  PRORLB 

NAME;  PROFILE  •  A  Otnarlo  Expert  Dltgnoatlclan 
YEAR;  1982, 1087 

FUNCTION;  Whan  uaad  aa  a  daaign  analyala  tool,  PROFILE  projaots  tha 
maintananoa  parformanoa  raquirad  for  aaoh  of  a  aampla  of  falluraa,  and  kaaps  track 
of  tha  raatona  for  axoaaalva  fault  raaolutlon  tima.  Among  Ita  summary  raeults  ara 
tha  following: 


•  Tha  diatrlbutlon  of  rapair  timaa,  with  maan  tIma  to  rapair 

•  An  analyala  of  tha  utllltlaa  of  all  Indicators  and  taat  points.  This  can 
highlight  maintananca  faaturaa  which  ara  radundant  or  of  marginal 
valua,  oonaldaring  thair  production  coat. 

•  An  analyala  of  falsa  raplacamanta.  Indicating  thosa  oomponanta  which 
ara  llkaly  to  ba  oonaumad  In  quantitlaa  graatar  than  thair  fallura  ratas 
would  Indloata.  This  also  foouaaa  attention  on  naada  for  additional 
Indicators  and  taat  points,  to  disorimlnata  batwaan  parts  whioh  produoa 
Identical  symptoms  under  tha  currant  design. 

•  A  summary  of  tha  types  and  fraquanolas  of  maintananoa  actions 
raquirad  to  resolve  tha  sample  of  faults,  and  tha  proportion  of  time 
spent  performing  those  funotlona. 

CAPACITY;  MuKI-unIt  systems 

CPU  TIME;  Intensive 

APPLICATION;  VLSI  PCS  SUBSYS  SYSTEM 

ACQUISITION  PHASE;  CONCEPT  DEMA/AL  EfiE  PaPCIN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/N  (UNIV)  Sea  last  comment. 

DESIGN  ENV;  Apollo,  Sun,  and  VAX  compatibility.  Written  In  Pascal. 

CIRCUIT  DESCRIPTION:  Mentor  Graphics  CAD  Interface  capability  available. 

USE  PREREQUISITE;  Data  concerning  manual  operations  time  consumption  and 
reliability  astlmatss. 
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DEVELOPER:  B«htvlor«l  Ttohnology  Labs,  UnIvtrsIty  of  Southern  California, 
supported  by  the  Office  of  Naval  Research 

COMMENTS;  PROFILE  la  also  useful  as  a  maintenance  training  system  and  a 
diagnostic  aid  tool. 

-  There  la  an  interest  In  the  success  of  PROFILE  by  government  officials 
so  that  MTTR  times  can  be  more  effectively  vetlfled. 

•  PROFILE  can  be  used  In  conjunction  with  ANDI,  a  simulator  with 
analog  and  digital  capabilities,  offered  by  the  Silver  Lleoo  Corporation. 

•  In  order  to  use  PROFILE  for  aubayatem/syatem  level  design,  one  must 
manually  Input  the  system  model.  SImuiatora,  similar  to  ANDI  for 
system-level  design,  are  helpful  however. 

-  At  present,  the  US  Qovemment  has  unrestricted  rights  to  the  software 
and  can  distribute  It  to  whomever  it  wants.  An  agency  has  not  yet 
been  established  to  do  this,  however.  Until  then,  one  may  obtain 
PROFILE  at  the  point  of  contact  listed  below. 

REFERENCES: 

1.  Towns,  D.  M.,  "A  Generic  Expert  Diagnostician,”  Proceedings  of  AF 
Workshop  on  Al  Applloatlona  for  ID,  University  of  Colorado,  July,  1986. 

2.  Towns,  D.  M.,  Johnson,  M.  C.,  and  Corwin,  W.  H.,  ”A  Performance 
Based  Technique  For  Aseeselng  Equipment  Maintainability,”  Los 
Angeles,  CA,  Behavioral  Technology  Laboratories,  University  of 
Southern  Callfomia,  Report  No.  TR-102. 

3.  Behavioral  Technology  Laboratories 
1845  South  Elena  Ave.  Fourth  Floor 
Redondo  Beach,  CA  90277 
(213)  640-3664 
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4.2.1 .7  STAMP 

NAME;  STAMP  •  System  TtstebllKy  And  Malnt«nanct  Program 
YEAR:  1980 

FUNCTION;  BIT  affootivanass;  FI  avaluatlon;  tastablllty  Improvamant 
raoommandatlons;  test  racommandatlona;  softwara  salf*test  daaign  validation; 
testability  maasuras;  multipla  (allura  dataotlon;  test  point  avaluatlon 

CAPACITY:  EOOO^nodaa 

CPU  TIME:  Fault  traas  may  taka  an  hour  or  mora  to  oomputa  at  tha  2000  noda 
laval. 

APPLICATION:  ^LSl  £2fi  8UB8YS  8XS.TEM 

ACQUISITION  PHASE;  CONCEPT  PEWVAL  £8Q  PRPCTN  PPLYMNT 

PUBLIC  DOMAIN?:  Y/N  ;  only  by  spaolal  arrangamant,  saa  first  oommant. 

DESIGN  ENV;  Appla  (aarllar  200>noda  vartion);  HP>1000/A900 

CIRCUIT  DESCRIPTION:  Logic  Modallng.  Knowladga  baaa  davalopmant 

USE  PREREQUISITE:  A  functional  block  diagram,  Including  test  points.  Is  tha  basic 
Input  to  STAMP.  Tha  program  will  maka  usa  of  teat  cost,  fallura  fraquanolas,  skill 
laval  and  othar  data,  as  wall  as  modHIoations  and  ovarrtdas  to  logic  and  Infaranoa. 

DEVELOPER:  ARINC  Rasaaroh  Corp. 

COMMENTS:  Tha  company  policy  Is  not  to  sail  or  laasa  STAMP,  but  rathar  to  sail 
and  provida  taatablllty  sarvioas.  STAMP  Is  an  assantlal  tool  that  ARINC  Rasaaroh 
amployoas  will  usa  thamsalvas  in  ordar  to  provida  thasa  sarvicas. 

STAMP'S  wida  ranga  of  applications  and  usaful  outputs  maka  It  a  highly  dasirad 
tool.  Tha  analysis  procass  Is  fully  hlararohicai. 
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STAMP  hat  23  difftrtnt  numtrlotl  TFOM  mtaturtt  that  raquira  contractor 
aaalatanca  (Raf[2]).  In  addition,  It  will  diraotly  compute  aptclfloatlon  oompllanoa 
numbtra.  It  will  ganarata  a  number  of  uaar  apaolflad  analyaaa,  and  generate  both 
aingle  and  multiple  failure  FMEAe. 

STAMP  will  alio  prepare  fault  Isolation  strategies  that  may  be  optimized  on  a 
number  of  ueer  Input  factors,  Including  the  generation  of  multiple  failure  and/or 
replaceable  unit  fault  trees. 

The  fault  treat  that  are  generated  are  useful  In  the  development  of: 

-  UUT  diagnostic  software  either  for  BIST  or  ATE  TPS. 

•  TRD  generation. 

•  Technical  troubleshooting  manuals.  An  IBM  PC/AT/XT  utility  has 
been  developed  for  this  purpose. 

STAMP  may  be  used  to  develop  the  fault  trees  utilized  by  portable  maintenance 
aids  or  the  Interactive  fauH  Isolation  atrateglea  that  they  employ  (ReftS]). 

STAMP  has  demonstrated  an  ability  to  predict  M>Demo  results  (Ref[1  ]). 

STAMP  Is  continually  being  Improved. 

One  recent  Improvement  Is  provision  for  IBM-PC  assistance  In  the  task  of  entering 
STAMP  dependency  Input  data.  This  utility  helps  make  this  task  less  tedious, 
reduoea  the  amount  of  proofreading  required,  and  reduces  the  chance  of  an 
erroneous  Input.  This  process  entails  transforming  a  list  of  elements  Into  a  picture 
which  Is  easier  to  check  and  work  with. 
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REFERENCES: 

1.  SImpion,  W.R.,  "STAMP  Tittabiilty  And  Fault  Isolation  Applloatlona, 
1981-84."  IEEE  AUTOTESTCON  1986. 

2.  Simpson,  W.R.,  and  J.R.  Agra.  "Exparlanoa  Qalnad  In  Tastablllty 
Ditign  Trada-Offa,"  IEEE  AUTOTESTCON  1984. 

3.  Simpson,  W.R.,  "Aotiva  Tastablllty  Analysis  and  Intaraotiva  Fault 
Isolation  Using  STAMP,"  IEEE  AUTOTESTCON  1987. 

4.  Naval  Ooaan  Systams  Cantar,  Tastablllty  Analysis  Tools  On  A  Military 
Systam,”  Taohnioal  Raport,  Saptambar,  1987. 

6.  ARINC  Rasaaroh  Coiporatlon 
Attn:  Or.  Randy  Simpson 
2651  RIvaRoad 
Annapolis,  MD  21401 
(301)266-4066 
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4.2.1 .6  TE8AP 

NAME:  T88AP  •  T«st  Strategy  Assastmant  Program 
YEAR: 

PUNOTiON;  Allows  tha  oomparlton  of  tha  coats  of  various  tasting  atrataglas  givan 
varying  fault  spaotra  to  maka  ganaral  assassmants  of  what  combination  of  tasts  art 
bast. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  VLSI  Efifi  SUB8Y8  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  PSD  PRDOTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/£l 

DESIGN  ENV;  V\frlttan  In  LOTUS  1-2-3 

CIRCUIT  DESCRIPTION:  Not  raquirad 

USE  PREREQUISITE;  Ona  must  antar  paramatars:  timas  of  tast/rapair,  tastar  POM, 
dafaet  rata;  also  labor  ratas,  #  of  boards,  ato. 

DEVELOPER:  Hawlatt  Packard 

COMMENTS:  As  a  product  matures,  Its  quality  Improves  and  thus  tha  likelihood  of  a 
fault  decraaaas.  This  program  advises  whan  certain  testa  are  no  longer  raquirad. 
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REFERENCES: 

1,  Hamilton,  S.  A..  "Optimizing  Teat  Strategy  Through  Computar’Aldad 
Taat.  ATE  Inatr.  Conf  Eaat,  1987. 

Piaaaa  nota  that  TESAP  la  not  baing  markatad;  howavar,  Inqulriaa  can 
ba  diraotad  to: 

Hawlatt  Packard  c/o:  Ellaan  N.  Maanan 

3  Croaawaya  Park  Waat  Salaa  Rapraaantativa 

Woodbury,  Naw  York  11797  Eiaotronlo  Inatrumanta 
(61 6)  682-7830/7800  Eaatam  Salaa  Ragton 
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4.2.1 .9  TIME 

NAME:  TIME  •  T4it«blllty  lnl«rfaotd  Miintaintblllty  Eatlmattt 
YEAR:  IQeQ(prototypt) 

FUNCTION:  TIME  la  an  automatad  maintainability  pradlotion  tool  which  takaa  Into 
diraot  account  tha  Inlluanoa  of  taatabiltty/dlagnoatlo  dasign,  and  maintananoa  and 
rapair  phlloaophlaa  on  maintainblilty.  Taatablilty  oharaotarlatloa  and  maintananoa 
phlloaophlaa  ara  diraotly  Inoorporatad  Into  tha  pradlotion  modal.  Thaaa  Inoluda 
fraction  of  faulta  laolatabla/dataotabla.  lavala  of  ambiguity,  application  of  aaoondary 
fault  laolatlon  maana  and  troublaahooting  oonoapta  partinant  to  various  lavala  of 
ayatam  Indantura.  Six  maintananoa  phlloaophlaa  ara  avallabla  from  which  to 
ohooaa.  Each  philosophy  has  aaparata  modala  for  computing  alamantal 
maintananoa  task  timaa.  Tha  task  modala  ralata  to  valuaa  for  avaraga  tima  raquirad 
to  dataot,  laolata,  aoquira.  diaaaaambla,  Intarohanga,  align,  raaaaambla,  ohaokout, 
and  atart<up. 

CAPACITY: 

CPU  TIME; 

APPLICATION:  VLSI  Efifi  mm  StSIEM 

Uaaful  for  ayatama  that  ara  oompoaad  of  ambiguity  groups  for  tha  purposa  of  fault 
Isolation  and  maintananoa. 

ACQUISITION  PHASE: 

PUBLIC  DOMAIN:  Y  (QFE)  (Whan  oompiata) 

DESIGN  ENV:  WrIttan  In  Turbo  Pascal  for  IBM  PCs. 

CIRCUIT  DESCRIPTION;  Tha  ayatam  Is  dasorlbad  by  Its  ambiguity  group  makaup. 

USE  PREREQUISITE:  Raquirad  Input  paramatara  Inoluda  various  taatablilty, 
maintainability,  and  rallablllty  varlablas  auoh  as:  failure  rates,  fraction  of  faulta 
laolatabla/dataotabla,  times  raquirad  to  diaasstmbla,  ramova  and  raplaoa, 
raaaaambla,  ohaokout,  align,  and  startup. 

DEVELOPER:  RADC/RBET  (Joa  Caroll) 

COMMENTS:  Tha  prediction  technique  Is  a  modification  of  MIL-STD’472, 
Prooadura  6. 
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REFERENCES: 

RADC/RBET  (Joe  Caroll) 
Qiifflu  AFB,  NY  13441-6700 
COMM:  (316)330-4205 
AV:  667-4206 
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4.2.2  PiMlt  Simulation  Tools 

This  section  contains  software  tools  available  that  are  a  subset  of  tools 
that  aid  In  the  prediction  of  the  effectiveness  of  testablllty/dlagnostio  capabilities.  In 
particular,  they  aid  In  predicting  the  TFOM,  fraction  of  faults  detected  (FFD). 

They  are  called  fault  simulation  tools  or  fault  simulators. 

Automatic  Test  Generation  (ATQ)  and  fault  simulation  go  hand-ln*hand 
and  sometimes  are  one  in  the  same  tool.  However,  for  classification  purposes, 
ATQs  can  be  found  In  this  appendix  for  design  Implementation  tools  under  the 
subheading  called  Diagnostic  Authoring  (3.3). 

Both  tasks  are  essential  during  the  design  and  evaluation  of  an  effective 
diagnostic  item. 

Many  systems  that  do  not  plan  to  Include  a  particular  diagnostic  capability 
as  part  of  thr^  design  process,  deploy  fault  simulators  siifiply  because  they  make  the 
production  validation  process  economically  feasible.  However,  these  tool 
capabilities  very  much  senre  In  the  assistance  of  Including  diagnostic  capabilities. 
For  eivample,  they  may  be  useful  In  assuring  ETE  effectiveness  or  compatibility,  for 
evaluating  test  vector  sets  deployed  by  BIT,  or  for  fault-tolerant  design  and 
evaluation. 

Tools  that  aid  In  fault  simulation  all  have  the  following  features  in 

commotr: 


-  They  would  be  deployed  during  the  Full-Scale  Development  Phaes  for 
the  purpose  of  deriving  an  effective  and  optimized  set  of  test  vectors 
necessary  to  perform  the  task  of  validating  the  functional  design  during 
production. 

-  They  all  apply  to  digital  circuitry  and  primarily  process  faults  at  the  gate 
level. 

-  Although  each  tool  is  capable  of  being  run  separately,  ATQs  and  fault 
simulators  are  almost  always  run  together.  The  ATQ  provides  the  test 
vector  set.  The  fault  simulator,  either  statistically  or  deterministically, 
evaluates  what  percentage  of  the  total  faults  considered  would  be 
detected  by  such  a  test  vector  set. 
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-  Sp««d  enhanctm«nt  is  this  family  of  tools  prims  compstHIvs  sport  and 
each  has  a  uniqua  way  of  rsmalning  in  tha  arana.  Rafar  to  tha  chart 
with  the  column  heading  "INCREASED  SPEED  METHOD*. 

A  summary  description  of  tools  that  aid  in  fault  slnriulation  are  provided  In 
the  following  table. 


ACRONYM  APPLICATION  INCRRA8ED  SPEED  MITWOD  CQMMiWTS 


AIDA 

visbfca/ 

•UtSYSTIM 

AM30008S4ULATORI8 
MOUNTED  INTO  THE  SCAN 
NONNOTATION 

PNOVmSEXOELllNT 

OSSKtNASSISTANOI 

•irawADi 

VUlifOS 

■BEOIAUZmM  FAULT 

4MA0SM  NANOOM  FArTEBN 
OENmATEO  TEST  VEOTONS 

DSTEFBASliS  THE  FAULT 
OOVENAOB  OF  BILBOS, 
MMAlIFSR|.BTO. 

CAOATt 

VUI/POi 

USES  OATS  AOOELIRATON 

ALLLIVELBOFOEVIOB 
MODBUNO  FROMSWITOH  UVEL 
TOHAROWARB 

H'TS 

VLSVPCS 

USESCONOUNMNT 

SMUUnON 

iWBMTS  in  TFS  DEVELOPMENT 

IKOSWO 

V  ■ 

8FSCIALFUNFOOS 

IIANDWANBLINNIDTO 

HOSTOOMfUTEN 

FAST 

UWAMVin*! 

JUtXKlA 

IWOMOUTOn 

VtMfOS/ 

1 

1 

POvT^wOlMNNO 

AVAEABLBTOMAKE 

STMUU  COMP*  TENS 
WITNTAIMETTIBm 

0UK3R»'„iaT 

SUtSVSTEM 

LAN  AOOfiLliMATIOII  MUOtL 

SUPPORTS  MANY  MOOflL 

rvFiSiSwrroHis 

SVSTtM 

OATES  MHAVIORAL. 

HARDWAM  MODELS, 
QUOKFAms 

•OOnATM 

VLSI 

USES  A  FAST  FAULT  SIM 
ANDSymOVBDATQFAN 

OARRMB  FIFO  HEURHTWAUV 
FRONTS  jTASEJTY  ANAL  TO 

ATO  ALOORffNMFROOISS 

8TAFAN 

VLSI 

OALOULATES  FAULT 

DSTSOTION  PNOSABIUTY 

ill 

Pi 

ill 

m 

STATaRAOE 

VUI 

BIB  ABOVE 

SHASOVB 

TBtranTAOc 

VLSVPOl 

CONOUFINENT  SIMULATION 

WITH  LAN  ACCBLENATION 

OPTION 

0PT1MD1TI8T 

VECTOR  BET  WITH 

STATQRADfi.  THEN 
USETESTORAOE 

THESEUS 

VL8I/PCB 

AFTER  EACH  TEST 

VECTOR.  ALL  DETECTED 

FAULTS  ARE  NO  LONCER 
CONSIDERED 

PROWOSS  AN  ALTERNATIVE  TO 
SCAN  DESIGN 

ZTCAO 

VL8I/PCB 

SUBSYSTEM 

SIMULATION  IMPLEMENTINO 

IN  HARDWARE  EMPLOYINO 
PARALLEL  PIPELINE 

PROCESSING  TECHNIQUES 

ZYCAD'B  NEXTGEN  IS  AN 
ACCELERATED  ATq 
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4.2.2.1  AIDA 

NAME:  AIDA  Fault  Simulation 
YEAR:  1987 

FUNCTION;  Tho  AIDA  Fault  Simulator  parforma  aooalaratad  full  or  partial  fault 
grading  at  workatatlona  for  taat  aat  avaluationa.  It  alao  providaa  a  fault  dictionary, 
Including  a  Hat  of  undataotad  faulta  and  looationa. 

CAPACITY:  5,000  •  1 ,000,000  gataa 

CPU  TIME;  Nagllgibla. 

APPLICATION;  yLSl  Efifi  SUBSY8  SYSTEM 

ACQUISITION  PHASE;  CONCEPT  DEMWAL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  X/U  (PRTY) 

DESIGN  ENV;  Qata  array  and  RISC  eo-procaaaor  mountad  into  an  Apollo 
workstation:  alao  on  Sun.  Thasa  tools  ara  part  of  AIDA  daaign  aystam  which 
Includes  a  logio  simulator,  a  timing  variflar,  and  othara.  They  also  aooapts  daaigna 
tranalatad  from  non<AIDA  ayatama. 

CIRCUIT  DESCRIPTION:  AIDA  daaign  language 

USE  PREREQUISITE; 

DEVELOPER:  AIDA  CORP.,  Santa  Clara,  Ca. 

COMMENTS;  Taatabillty  can  be  achieved  quite  afficiantiy  with  this  approach.  Up  to 
100%  testability  If  scan  design  methodology  for  targeted  system  Is  used.  AIDA  also 
supports  Boundary  Scan. 

•  The  AIDA  Fault  Simulator  can  be  used  with  the  AIDA  ATPQ.  When 
the  ATPQ  creates  a  test  vector,  the  Fault  Simulator  automatically 
checks  what  other  fault  classes  can  be  detected  by  that  vector. 
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•  Both  tho  AIDA  Fault  and  Loflio  SImulatora  ara  acoalaratad  by  tha  AIDA 
Co  Simulator  procai tor. 

•  AIDA  raoantly  aoquirad  by  Taradyna;  rafar  to  Latar  Varslon  6. 
REFERENCES: 

Plarra  Wildman,  Product  Markating  Managar 

G/o  AIDA  Corporation 

5165  Old  Ironaldaa  Driva 

Santa  Clara,  Ca.  05064 

(408)080-5200 
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4.2.2.2  BITQRADe 

NAME:  BITQRADB  •  Built-In  T«tt  Qrtd* 

YEAR;  1986 

FUNCTION:  BITQRADE  dtUrmlntt  fault  covaraga  for  aalMast  dtaigna.  la 
Intaraotlva,  and  la  not  hindarad  by  scan  daaigns. 

CAPACITY; 

CPU  TIME:  (Bxampla)  9.386  almulatad  faults,  raquiring  256  random  taat  pattama. 
oonsumad  694  taoonda  of  CPU  tima  using  a  66010  basa  workstation. 

APPLICATION:  ^  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  £S&  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  iC/N  (PRTY) 

DESIGN  ENV:  Thara  ara  varslons  for  Apollo.  SUN.  VAX.  IBM;  usad  In  conjunction 
with  VERILOQ.  TESTQRADE.  TESTSCAN.  STATQRADE.  and  POBLIB.  othar 
Qataway  products. 

CIRCUIT  DESCRIPTION:  BITQRADE'S  HDL 

USE  PREREQUISITE;  Entar  circuit  description  from  a  natllst  or  a  hardware 
description  at  a  gate  level. 

DEVELOPER:  Qataway  Design  Automation  Corporation. 

COMMENTS;  Self-test  random  pattern  generators  can  require  hundreds  of 
thousands  of  test  patterns.  BITQRADE  is  spaolfloally  designed  to  deterministically 
fault  grade  these  tests. 

•  After  LFSR  and  MISR  descriptions  are  Input,  BITQRADE  determines 
their  capability. 

-  It  supports  all  scan  designs. 
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REFERENCES: 

Qatvway  DtsIgn  Automation  Corporation 
6  Llbarty  Way 
PO  Box  573 
Wastford.MA  01685 
(617)692-9400 
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4.2.2.3  CADAT  9  Piult  Simulator 
NAME:  CADAT  6  Fault  Simulator 
YEAR: 

FUNCTION:  Tha  CADAT  Fault  Simulation  option  utlllzas  a  functional  Conourront 
Fault  Simulation  algorithm  to  analyze  tha  impact  of  potantlal  manufacturing  errors 
and  circuit  failures.  The  algorithm  optimizea  simulation  throughput  for  all  levels  of 
device  modeling,  from  switch  level  to  hardware. 

CAPACITY: 

CPU  TIME: 

APPLICATION:  ytSl  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESC  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  Y/N  (PRTY) 

DESIGN  ENV:  CADAT  6  will  run  on  the  following  hardware  platforms; 

Apollc/AEQIS  with  AUX 

IBM  PC-A't/PC-DOS  (Personal  Cadet) 

IBM  MVS 

IBM  VM/CMS 

SUN  Microsystems  UNIX 

VAX  ULTRIX 

VAX  VMS 

LANA  (Local  Ares  Network  Aocelsration)  Is  also  available. 

CIRCUIT  DESCRIPTION;  Behavioral  Design  Language  (BDL) 

USE  PREREQUISITE:  Behavioral  description  or  a  circuit  netlist  must  be  input. 
DEVELOPER:  HHB  Systems 
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COMMENTS:  Rtf«r  to  CAOAT  6  In  tht  Tools  For  Doslgn  Aid  iootlon. 

REFERENCES: 

HHB  Syttomi 

Attn:  Mr.  Ktnntth  Upiton 

1000  WyoKoff  Avo. 

Mahwth.NJ  07430 
(201)  846-8000 
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4.2.2.4  HITS 

I  NAME:  HITS  •  Hi«rarohio«l  Irrttgrattd  Ttat  Simulator 

i 

YEAR;  1987  -  HITS  14 

I  FUNCTION:  HITS  li  a  Digital  Automatic  Tatt  Program  Qantrator  (DATPQ)  toftwara 

•yatam.  Ita  funotlona  aa  a  aoftwara  tool  ara  to  aaalat  In  tha  davalopmant  of  digital 
;  Taat  Program  Sata  (TPS)  and  to  aarva  aa  a  maana  to  avaluata/varify  digital  daaigna. 

;  Tha  modulaa  of  particular  Intaraat  ara: 

•  PRIMARY  MODEL  PROCESSOR  •  Compllaa  and  prooaaaaa  tha  uaar- 
dafinad  natworH  modal  and  produoaa  tha  Initial  circuit  topology  tablaa 
and  data  baaa. 

•  SWAPPER  -  Datarmlnaa  tha  circuit  or  network  modal  fault  univaraa, 
and  on  aubiaquant  axaeutlona,  at  tha  uaar'a  option,  tha  SWAPPER 
will  produoa  fault  aagmanta  or  fault  partitlona  for  circuit  alamanta 
Idantiflad  by  the  uaar.  Tha  SWAPPER  craataa  fault  aquivalanoa 
olaaaaa  required  by  tha  TEST8IM  module. 

.  TEST8IM « Tha  function  of  thia  modula  la  to  ganarata  and  avaluata 
taat  pattama  to  detect  tha  falluraa  being  oonaldarad  for  tha  currant  taat 
aagmant. 

•  SIMULATE  •  Parforma  fault  fraa  and  fault  almulatlon  uaing  a 
oonourrant  mathodology.  Ita  function  la  to  datarmlna  tha  quality  of 
atimulua  for  tha  givan  circuit  topology.  It  datarmlnaa  fault  dataotlon, 
faun  laolatlon,  and  produoaa  tha  faun  dictionary. 

•  PROBE  -  Tha  PROBE  modula  la  provided  aa  a  backup  to  tha  primary 
maana  of  fault  laolatlon,  which  la  tha  faun  dictionary.  If  tha  numbar  of 
Indloatad  replaoaabla  packagaa  la  too  high  for  an  laolatad  failura,  tha 
data  ganaratad  by  tha  PROBE  modula,  In  oonjunotlon  with  aultabla 
hardware  on  tha  ATE,  can  ba  uaad  to  laolata  to  tha  fallad  noda. 

CAPACITY;  Tha  maximum  HITS  can  prooact  la: 

•  150,000  nodaa 

•  76,000  nata 

•  60,000  blocks 

•  32,000  fault  laolatlon  aata 

CPU  TIME: 
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APPLICATION:  ^LSl  PCB  SUBSYS  SYSTEM 
ACQUISITION  PHASE:  CONCEPT  DEM/VAL  £SD  PRDOtN  PPLYMbll 
PUBLIC  DOMAIN?:  1/N  (QFE) 

DESIGN  ENV;  VAX  11/7XX;  FORTRAN  •  77  (O/S:  VMS,  UNIX) 

CIRCUIT  DESCRIPTION:  HITS  uMt  «  Circuit  Dticrlptlon  Language  (CDL),  which 
it  almllar  to  a  wira-llat  format,  la  almpla  to  uaa,  eontalna  ATLAS-llka  atatamanta, 
providaa  tha  capability  to  antar  ROM/RAM  &  PLA  data,  and  providaa  tha  capability 
to  antar  "blacK  box*  modala  uaing  tha  Raglatar  Tranafar  Language  (RTL)  tool. 

Tha  RTL  la  PaacaMIka  and  anablaa  uaara  to  write  behavioral  daaorlptlona  of 
modala/componanta  which  lack  atructural  detailed  Information. 

In  addition,  tha  uaar  may  define  unique  MACROS,  acoaaa  a  ayatam  MACRO  library, 
and/or  utilize  ayatam  primitivaa  oompoaad  of  combinational  gataa,  aaquantlal 
davicaa,  and  functional  primitivaa.. 

USE  PREREQUISITE:  One  muat  Input  daaorlptlon  of  UUT  Into  modal  procaaaor 
module,  Identifying  oomponenta  from  HITS  atandard  cell  library,  or  uaa  ayatam 
primKIvaa. 

DEVELOPER:  Naval  Air  Engineering  Canter 

COMMENTS:  HITS  la  vary  Inexpenalva  and  la  alwaya  being  updated  and  Improved. 

In  order  to  avoid  axcaaalve  CPU  time  while  uaing  HITS,  tha  UUT 
ahould  be  wall  dealgnad  for  teatablllty. 

•  Praaantiy,  HITS  la  predominantly  uaad  for  modulaa  Integrated  with 
MSI/LSI/VLSI  oiroulta. 

•  TPS  development  on  a  firm  fixed-  price  basla  algnlflcantly  increases 
management  risks.  Uaing  HITS  requires  taking  action  to  minimize  cost 
and  scheduling  risks  and  Improve  product  quality.  See  Ret[2]  below. 
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REFERENCES: 

1.  HITS  UMrt  Quid* 

Avionlot  Support  Equipment  DIv. 

Naval  Air  Enginaartng  Cantar 

Lakahurat,  N  J.  08733 

TR-AIRTASK  A662-6622/081D/3W08620000 

2.  Qorham,  Q.B.,  "Managing  Risk  In  tha  HITS  Environmant,"  Tast  & 
Maaauramant  World  (magazina),  Nov  1087,  p  26. 
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4.2.2.S  iK08  800 
NAME:  IK08800 
YEAR:  1086 

FUNCTION:  A  cMilgn  vtrifloitlon  tytttm  offtrlng  hlgh*tpMd  ttlmului  prootsilng 
and  aocalaratad  loglo  simulation  by  maana  of  apaolaLpurpoaa  hardware  linktd  to  a 
boat  oomputar. 

A  unique  IKOS  Waveform  Capture  Stimulus  QerMrator  la  provided  that  should  prove 
to  be  a  oonsiderable  Improvement  over  traditional  stimulus  generation  methods 
allowing  the  ASIC  designer  to  quickly  create  millions  of  simulation  vectors  that 
emulate  real  system  operation. 

In  addition  to  faulMree  simulation  for  loglo  validation,  the  IKOS  800's  Loglo 
Simulation  Hardware  Accelerator  supports  high*apeed  stuok-at  fault  simulation  In 
unlt<lelay  simulation  mode.  The  user  may  specify  a  table  of  faults  to  be  simulated 
or  may  elect  to  simulate  all  possible  stuok*at  faults.  The  fault  coverage  report  lists 
all  faults  which  have  not  been  detected  by  the  proposed  test  program  and  those 
faults  may  be  recycled  back  Into  the  fault  table  for  ra|^  re<almulatlon. 

CAPACITY:  For  the  Stimulus  Processing  Hardware  Accelerator  the  capacity  has 
the  following  linear  relationship  wKh  the  amount  of  Stimulus  memory  available; 

•  4  MBYTE  of  Stimulus  memory;  2.6  million  I/O  events 

•  8  MBYTE  of  Stimulus  memory:  5  million  I/O  events 

•  16  MBYTE  of  Stimulus  memory;  10  million  I/O  events 

For  the  Loglo  Simulation  Hardware  Accelerator  the  capacity  has  the  following  linear 
relationship  with  the  number  of  Evaluator  boards  available; 

1  Evaluator  board;  1 6  thousand  primitives 

•  2  Evaluator  boards;  32  thousand  primitives 

•  3  Evaluator  boards;  48  thousand  primitives 

4  Evaluator  boards:  64  thousand  primitives 

CPU  TIME:  For  the  Stimulus  Processing  Hardware  Accelerator,  the  rate  at  which 
the  resident  stimulus  is  presented  is  one  million  I/O  events  per  second. 
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For  thf  Logic  Simulation  Hardware  Accelerator,  the  rate  at  which  the  events  are 
processed  In  the  Timing  Mode  Is: 

•  1  Evaluator  board:  .6  million  I/O  events  per  second. 

•  2  Evaluator  boards:  1  million  I/O  events  per  second. 

•  3  Evaluator  boards:  1 .6  million  I/O  events  per  second. 

•  4  Evaluator  boards:  2  million  I/O  events  per  second. 

The  rates  at  which  the  events  are  processed  In  the  Unlt*Delay  Mode  are  ten  times 
faster  tnan  the  rates  of  the  Timing  Mode. 

APPLICATION:  ^LSl  PCB  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESfi  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  i^/N  (PRTY) 

DESIGN  ENV: 

Hoat  Computers:  Hort  Data  Link: 

•  IBM  PC/AT  •  6  MBIt/seoond  aerial 

link  with  standard 
2S  pin  RS232  connectors 


•  IBM  PC/RT  (future  support) 

'  Apollo  DN3000  Maximum  uable  length; 

(future  support)  60  ft.  (1 6.2m) 

CIRCUIT  DESCRIPTION;  IKOS  Systems  provides  both  functional  and  timing 
libraries  for  a  number  of  commercial  semi-custom  vendors.  In  addition,  the  IKOS 
800  Includes  library  development  tools  to  allow  users  to  Input  new  semi-custom 
libraries  or  adit  existing  llbraiies.  The  basis  of  the  IKOS  800  library  support  tools  Is 
the  Delay  Form  and  the  user  Is  provided  with  Delay  Forms  for  a  wide  variety  of 
common  seml-oustom  macro-cell  functions  (e.g.,  Iwo-lnput  NAND  gate,  D  flip-flop 
with  preset,  clear  and  acan  test  Inputs,  etc.). 

USE  PREREQUISITE:  The  IKOS  800  will  accept  semi-custom  netllsts  In  a  variety  of 
formats.  The  IKOS  800  netllst  compiler  will  combine  the  user  netllst  with  seml- 
oustom  library  data  and  create  the  data  base  required  for  simulation.  The  netllst 
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compllor  can  link  multiple  netllets  representing  Individual  "pages*  of  a  single  design 
or  complete  netllsts  for  several  different  ciroults. 

DEVELOPER:  IKOS  Systems,  Ino. 

COMMENTS:  IKOS  gives  substantial  Improvement  In  simulation  speed  over 
software  simulators  *  an  8*hour  simulation  on  a  Mentor/DN  3000  takes  less  than  30 
seconds  on  the  IKOS  simulation  system. 

Much  simulation  Is  a  good  thing.  The  more  the  design  engineer  oan  simulate  the 
more  he  oan  test  and,  therefore,  the  more  likely  It  Is  that  his  circuit  will  work 
correctly.  Being  able  to  rapidly  simulate  Is  crucial  to  being  able  to  abundantly 
simulate. 

IKOS  currently  supports  32  ASIC  libraries  from  16  ASIC  vendors. 

Asynchronous  system  interfaces  to  the  ASIC  oan  be  simulated. 

In  order  to  minimize  netllst  compile  time,  the  IKOS  800  caches  the  appropriate  semi* 
custom  library  data  In  hlgh*speed  RAM. 

REFERENCES: 

IKOS  Systems,  Ino. 

146  N.  Wolfe  Road 
Sunnyvale,  CA  94086 
(408)  246  1900 
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4.2.2.6  LASAR  VERSION  6  -  JUDGE 
NAME:  LASAR  VERSION  6 -JUDGE 

YEAR:  1982,  origin  1978 

FUNCTION:  LASAR  Version  6  provides  a  CAD  simulation  system  for  design 
verification  and  test  program  generation  Incorporating  a  testability  subprogram 
called  JUDGE.  JUDGE  provides: 

-  A  fast,  concurrent  time-based  simulation  of  stuck-at  0,  1 ,  Z,  and  X 
faults,  opens,  and  shorts. 

•  An  accurate  measure  of  test  thoroughness:  the  user  can  decide  when 
the  desired  level  of  fault  ooverage  has  been  reached,  or  where 
addHional  test  vectors  are  needed  to  meet  fault  coverage  objectives. 

-  Identification  of  undetected  faults,  possible  redundant  circuitry, 
testability  problems,  or  logic  errors. 

•  Refer  to  Section  3.1.7  for  more  information  on  LASAR  and  to  Section 
3.3.2.3  for  more  Information  on  the  ATPQ  component  of  LASAR  oallea 
PROSECUTOR.  The  JUDGE  and  PROSECUTOR  subprograms, 
working  together,  provide  an  Integrated  environment  for  determining 
the  test  effectiveness  of  digital  circuity. 
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4.2.2.7  QUICKPAULT 
NAME:  QUICKFAULT 
YEAR: 

FUNCTION:  An  Interactive  determlnletlo  fault  simulator  with  the  following  features: 

•  Local  Area  Network  (LAN)  acceleration 

-  12  simulation  states;  (1 ,0,X)  (strong,  resistive,  HI  Z,  Indeterminate) 

•  Supports  all  Mentor  Graphics  model  types  (switches,  gates, 
behavioral,  hardware  models.  Quickparts) 

•  Statistical  projection 

•  FauHs  displayed  on  schematic 

•  Reports  actual  and  percent  detected,  possible  detected,  oscillatory, 
and  undetected  faults 

•  Fault  detection  charts 

•  Fault  dictionary 

-  "Stuck-at”  fault  model  (Input  and  output  pins) 

•  Interactive  fault  selection 

-  Hierarchical  selection 

•  Graphical  fault  selection 
Pause/Restart  and  Save/Restore  capability 
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CAPACITY: 

CPU  TIME:  Extensive  Jobs  require  overnight  runs 

APPLICATION;  Efii  SU8SYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  PSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (PRTY) 

DESIGN  ENV;  Mentor  Graphics  engineering  workstations 

CIRCUIT  DESCRIPTION:  See  above  for  all  Mentor  Graphics  model  types 

USE  PREREQUISITE:  Schematic  muat  be  captured  using  a  Mentor  Graphics  model 
type;  use  with  QUICKSIM. 

DEVELOPER:  Mentor  Graphics  Corporation 

COMMENTS:  Listed  below  are  some  further  advantages  of  QUICKFAULT: 

•  Displaying  results  graphically  on  the  sohematio  oan  save  tens  to 
hundreds  of  hours  of  analysis  time. 

•  Having  test  vectors  developed  and  evaluated  using  the  same  design 
engineering  data  base  saves  time  and  money. 

•  Provides  friendly  user  prompts, 

<  The  performance  Increase  with  LAN  acceleration  Is  typically  .9N, 
where  N  is  the  number  of  workstations  used  In  the  analysis,  and  1  Is 
the  analysis  time  on  one  workstation.  For  example,  a  benchmark  on  a 
large  gate  array  design  took  15  hours,  40  minutes  on  one  DN  3000. 
Using  three  DN  3000s,  the  run  time  was  reduced  to  5  hours,  20 
minutes. 

•  Behavioral  Logie  Models  (BLMs)  are  an  effective  modeling  method  for 
use  with  QUICKFAULT.  BLMs  have  proven  to  be  an  effective  method 
of  addressing  the  Increasing  complexity  of  fault  simulation  for  board 
and  system  level  designs. 
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REFERENCES; 

Frank  BInnankyk 
Product  Managar 
Design  and  Analysis  Division 
Mentor  Qraphics  Corporation 
8500  S.W.  Creekside  Place 
Beaverton,  OR  97006-7191 
(503)  626-7000 
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4.2.2.8  8TAFAN 

NAME:  8TAFAN  •  Statistical  fault  ^alysls 
YEAR:  1984 

FUNCTION:  STAFAN  parlorms  a  fault-fraa  logic  simulation  and  the  data  collected  Is 
used  to  calculate  the  fault  detection  probability  for  stuok-at-one  and  stuok-at-zero 
faults. 

CAPACITY:  3,000.000  gates. 

CPU  TIME:  Will  Increase  linearly  as  the  number  of  gates  Increase.  Please  note 
that  CPU  time  will  Increase  exponentially  for  traditional  determlnletio  fault 
evaluation. 

APPLICATION:  (Planned  extension  to  PCB) 

ACQUISITION  PHASE:  CONCEPT  DEIWVAL  fSB  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?:  ^/N  (PRTY) 

DESIGN  ENV:  The  development  program  was  done  on  a  CMOS  VLSI  fault 
simulator;  It  Is  presently  part  of  MIDAS  •  Modular  Integrated  j^eslgn  iS^utomatlon 
System,  Control  Data's  design  support  environment. 

CIRCUIT  DESCRIPTION;  MIDAS'  Logic  Intert^nneot  Language  netllet. 

USE  PREREQUISITE;  FaulMree  simulation  of  the  VLSI  circuit. 

DEVELOPER:  InHIally  AT&T  BELL  Labs;  currently  Control  Data  Oorp, 

COMMENTS:  STAFAN  adds  only  a  small  overhead  to  the  fault-free  simulation  task, 
requiring  two  operations.  The  first  Involves  updating  the  zero  and  one  counters  for 
every  test  vector,  and  the  other  Involvee  computing  statistical  controllabilities, 
observabilities,  detection,  and  fault  coverage,  which  Is  only  performed  once  every  N 
vectors.  Thus  STAFAN's  main  overhead  Is  due  to  updating  the  counters. 

Application  of  STAFAN  Is  limited  to  combinational  circuits. 
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REFERENCES: 

1.  Jain,  8.K.,  Agrawal,  V.  D.,  "STAFAN:  An  Altarnative  To  Fault 
Simulation,”  Dtaign  Automation  Conftronoo,  1984. 

2.  Control  Data  Corporation 
Attn;  Robart  BIgga  HQM274 
ADAM  MarkatIng 
MInnaapolia,  MN 
(612)863-3117. 
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4.2.2.9  8TATQRADB 
NAME:  8TATGRADE 
YEAR:  1987 

FUNCTION:  It  tttlmatts  total  fault  oovaraga  of  tast  vactora  through  atatlatloal  fault 
analyala.  Aftar  maaauring  CY  &  OY  valuta  of  almulatad  circuit  nodta,  tha  program 
will  output  tha  fault  oovaraga  of  a  givan  taat  vaotor.  It  alao  llata  atatlatloally 
undataotad  faulta  to  promota  Intaraotiva  taat  ganaratlon  for  apaolflo  araaa. 

CAPACITY: 

CPU  TIME:  20  to  60  timaa  faatar  than  eonourrfnt  fault  almulatora 
APPLICATION:  ^  PCB  8UBSY8  SYSTEM 
ACQUISITION  PHASE:  CONCEPT  DEM/VAL  ESD  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?:  ^  (PRTY) 

DESIGN  ENV:  Workatatlona  to  mainframaa,  Inohjding  APOLLO  &  SUN  w/a;  DEC 
VAX  &  MICRO  VAX  oomputara;  IBM  mainframa.  It  la  wrfttan  In  FORTRAN*??. 

CIRCUIT  DESCRIPTION:  STATGRADE'a  HDL;  Uaar  dafinad  MACROa  ara 
poaaibla  and  axtanalva  prlmKIvaa  ara  avallabla. 

USE  PREREQUISITE:  Build  a/w  modal  of  tha  oiroult  wHh  STATGRADE'a  HDL;  uaa 
In  oonjunotlon  with  VERILOG.  TESTSCAN,  TESTGRADE,  and  BITGRADE,  othar 
Gataway  aoftwara  produota. 

DEVELOPER:  Gataway  Daaign  Automation  Corp. 

COMMENTS;  STATGRADE  la  uaad  to  firat  aatabllah  a  aat  of  taat  vaotora  and 
provida  a  raaaonabla  oonfidanoa  In  how  affaotiva  thia  aat  of  taat  vaotora  la. 
Aftarward  a  mora  aoourata  fault  oovaraga  datarmlnatlon  can  ba  mada  with  a  fault 
almulator(TESTQRAOE). 

STATGRADE  can  Intarfaoa  with  othar  CAE  ayatam  taat  pattam  aata. 
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REFERENCES: 

Qattway  Dasign  Automation  Corporation 
Six  Llbarty  Way 
PO  Box  573 
Wtatford.  Ma.  01866 
(617)692-9400 
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4.2.2.10  TB8TQRADB 
NAME:  TB8TQBADB 
YEAR:  1087 

FUNCTION:  Conourr«nt  prooasslng.  comparing  a  faultad  maohina  with  a  good 
maohina  modal.  Onoa  a  sat  of  tast  vactors  Is  davalopad,  TESTQRADE  can  oraata  a 
fault  dictionary,  a  Hating  of  spaclflo  faults  with  assoolatad  raaponsas  to  givan  taat 
vactor  Inputs.  Taat  pattam  grading  datarmlnaa  tha  affaotivanaaa  of  a  taat  sat. 

CAPACITY:  Random  fauH  sampling  and  Inoramantal  taat  grading  maka  prooasaing 
larga  jobs  mora  faasibla. 

CPU  TIME:  Ordars  of  magnituda  fastar  than  aarilar  ganaratlon  fault  simulators 
APPLICATION:  YLSl  ESfi  SUB8YS  SYSTEM 
ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESQ  PRDCTN  DPLYMNT 
PUBLIC  DOMAIN?;  X/H  (PRTY) 

DESIGN  ENV:  Workstations  to  mainframas,  Including  APOLLO  &  SUN  w/s;  DEC 
VAX  8  MICRO  VAX  oomputara;  IBM  malnframa;  ELX8I  multi  •  oomputara.  It  is 
wrlttan  In  FORTRAN-77. 

CIRCUIT  DESCRIPTION:  STATGRADE's  HDL;  Usar  dafinad  MACROS  ara 
possibla  and  axtanalva  primitivas  ara  avaliabia. 

USE  PREREQUISITE:  Build  s/w  modal  of  tha  circuit  with  TESTQRADE'a  HDL;  uaa 
In  conjunction  with  VERILOQ,  TESTSCAN,  STATGRADE,  and  BITQRADE.  other 
Qataway  software  products. 

DEVELOPER:  Qataway  Design  Autemation  Corporation 

COMMENTS:  TESTQRADE  provides  a  facility  to  ganarata  tast  patterns 
automatically. 

It  accepts  tast  and  raaponsa  patterns  from  other  simulators. 

There  Is  a  parallel  processing  version  using  multiple  workstations  for  spaad 
Improvement. 

it  uses  proprietary  taohniquas  to  reduce  tha  memory  required  for  storing  faulty 
maohina  models. 
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REFERENCES: 

Qtt«w«y  DMign  Automation  Corporation 
Six  Llbarty  Way 
PO  Box  673 
Waatford.MA  01886 
(817)692-g400 


c-iee 


DESIGN  AUTOMATION  TOOLS 


APPENDIX  C 


J 


4.2.2.11  ZYCAD 


NAME:  ZYCAD  Fault  Evaluator 
YEAR:  1986 

FUNCTION:  Parform  fault  simulation  tasks.  It  Impismsnts  ths  simulation  In 
hardwars  smploylng  parallsl  pipsllns  proosssing  tschniquss.  This  affords  grsatsr 
spsed  than  possibis  with  sottwars  routinss  which  must  fstoh  Instructions  from 
s)(ternal  msmory  and  sxsouts  ths  m  ssqusntlally. 

CAPACITY;  up  to  61 2K  gatss 

CPU  TIME:  Clalmsd  spssd  up  to  200  timss  faster  than  software  based  simulators 
on  mainframe  computers. 

APPLICATION:  £!£B  8UB8YS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  l/U  (PRTY) 

DESIGN  ENV: 

tliglyyin.; 

DEC  VAX 
DEC  VAX 
IBM 
Apollo 
Sun 


VMS  3.7  /  VMS  4.0 
ULTRIX  (Berkeley  4.2  UNIX) 
MV8/2.0/CMS 
AEGIS  9.X 
UNIX  4.x 


CIRCUIT  DESCRIPTION;  Host  converts  user's  netllst  to  Zyoad  Intermediate  Format 
(ZIF).  ZIF  can  bo  used  by  other  ZYCAD  simulators.  ZIF  Is  not  a  simulation  netllst 
Isnguage. 

USE  PREREQUISITE:  Conversion  to  ZIF.  ZIL08  and  NEXTQEN  ATG  Interfacing 
available. 

DEVELOPER:  ZYCAD 
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COMMENTS:  The  concurrent  fault  simulation  algorithm  Is  based  on  the  event* 
driven  logic  simulation  algorithm.  The  concurrent  algorithm  only  processes 
modeling  elements  which  are  active  (switching).  Any  modeling  element  or  group  of 
modeling  elements  which  Is  not  active  Is  Ignored. 

Users  determine  the  number  of  timee  a  fault  Is  potentially  detected  until  It  Is 
considered  a  hard  detected  fault. 

Use  of  ZILOS,  a  friendly  simulation  environment,  promotes  the  uee  of  the  same  data 
base  files  for  logic  simulation,  fault  simulation,  test  analysis,  and  test  generation. 

A  number  of  optional  translators  are  available  that  enable  engineers  to  convert  their 
design  descriptions  to  ZILOS  format  and  Immediately  run  simulations  on  the  Fault 
Evaluator  without  dlsniptlng  existing  tools: 

•  Daisy  to  ZILOS 

•  Mentor  to  ZILOS 

•  TEQAS  to  ZILOS 

•  HILO  to  ZILOS 

The  following  Interface  to  the  Fault  Evaluator  within  the  existing  simulation 
environment: 

•  LSI  Logic  MDE 

•  GDC  MIDAS 
■  CAEH-EK 

REFERENCES: 

ZYCAD 

3000  Northwoods  Drive,  SuHe  200 
St.  Paul,  MN  66112 
(612)  490*2600 
(800)631  *6040  (wHhIn  MN) 
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5.0  DEMONSTRATION  TOOLS 

This  St otion  contains  tools  available  to  aid  In  the  task  of  demonstrating 
the  effeotivenesa  of  system  diagnostics. 

Only  one  tool  Is  Included  at  this  time. 


C-189 


DESIGN  Al/TOMATION  TOOLS 


APPENDIX  C 


J 


5.1  MIL>8TD*471A  MalnUlnablllty  Varlfloation,  Damonatration, 
■valuation 

YEAR:  1978 

FUNCTION:  Providaa  atandard  prooaduraa  for  avaluatlon  and  damonatratlon  of 
aquipmant/ayatam  bullHn  taat  and  axtamal  taat  aubayatam  fault  laolatlon  and 
taatablllty  attrlbutaa  which  ralata  to  maintainability  and  varloua  loglatic  aupport 
faotora  which  ara  Impaotad  by  maintainability. 

CAPACITY:  N/A 

CPU  TIME:  N/A 

APPLICATION:  VLSI  e£B  8UB8Y8  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEMA/AL  ESC  PRPOTN  DPLYMNT 

PUBLIC  DOMAIN?: 

DESIGN  ENV:  Panoll.  papar,  and  taattng  faoilltlaa. 

CIRCUIT  DESCRIPTION: 

USE  PREREQUISITE:  Ampla  davaiopmant  or  ralaaaa  of  tha  ayatam  raquiring 
diagnoatio  capability. 

DEVELOPER:  Rcma  Air  Davaiopmant  Cantar/RBE 

COMMENTS:  Conaldaring  tha  mammoth  taak  of  althar  aatabllahing  oontraotual 
raquiramanta  or  parforming  tha  actual  taak  of  damonatrating  and  validating  a 
ayatama  diagnoatic  capability,  thia  atandard  la  q».ilta  good. 

Aftar  ravlawing  a  aarlaa  of  taata,  aa  daacribad  In  thia  atandard,  aound  anginaaring 
Judgmant  playa  an  Important  rola  In  thia  taak  baoauaa  tha  ruling  aa  to  how  wall  a 
ayatam  la  diagnoaad  will  navar  ba  black  or  whita. 
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REFERENCES: 

Naval  Publications  &  Forms  Center 
Attn:  RFC  1032 
6801  Tabor  Ave. 

Philadelphia,  Pa.  19120 


C-192 


DESIGN  AUTOMATION  TOOLS  APPENDIX  C 

6.0  MATURATION  TOOLS 

This  section  contains  software  tools  available  to  aid  In  the  task  of 
diagnostic  capability  maturation. 

Only  two  tools  are  listed  In  this  section  at  this  time. 
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6.1  CITS/CEPS 

NAME:  CITS/CEP8  •  Central  Integrated  Test  System/CITS  Expert  Parameter 
System 

YEAR: 


PH  I .  CONCEPT  (6  1/2  MO)  1986 

PH  II  •  DEM/VAL  (17  1/2  MO)  1986  •  1987 

PH  III  •  PRODUCTION/DEPLOYMENT  (expected  start  9/88) 

FUNCTION:  CEPS  Is  a  rule-based  expert  system,  Initially  targeted  to  Increase  fault 
Isolation  through  the  use  of  expert  system  technology.  As  a  ground-based 
maintenance  aid,  It  Is  Intended  to  reduce  maintenance  man  hours  expended 
resolving  ambiguous  failures,  false  alarms.  repeaVrecurrlng  write-ups,  cannot 
dupllcatos,  and  retest  okays. 

To  accomplish  this,  CEPS  accesses  a  significant  amount  of  on-board  recorded 
parametric  data,  and  ground-based  maintenance  historical  data.  The  on-board 
recorded  data  Is  provided  by  the  CITS  system,  and  Is  augmented  by  design,  and 
maintenance  expertise,  and  combined  with  the  historical  tracking  mechanism  that  is 
part  of  the  CEPS  system.  The  provision  of  this  type  of  tracking  system,  provides  a 
natural  source  of  feedback  from  field  experience,  which  can  be  readily  available  for 
future  design  and  development  of  weapon  systems. 

CAPACITY:  N/A 

CPU  TIME:  N/A 

APPLICATION:  VLSI  P£i  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?:  ^/N  (QFE)  See  first  comment 

DESIGN  ENV:  Expert  system  demonstrated  on  a  Symbolics  computer  and 
converted  to  run-tIme  system.  It  Is.flplded  on  a  MIcrovax  II,  which  also  contained  a 
Data  Base  Management  System  (DBMS). 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE:  Access  to  existing  maintenance  AF  Management  Information 
System  (MIS)  called  CAMS  (Core  Automated  Maintenance  System),  used  for 
tracking  maintenance  actions. 
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DEVELOPER:  Rockwell  International  under  contract  from  the  US  Air  Force. 

COMMENTS:  It  Is  at  this  time  premature  to  tell  to  what  extent  the  government  will 
allow  public  access  to  CEPS  material.  The  software  Itself  basically  only  applies  to 
the  B-1B  aircraft.  What  is  're-usable,'  however,  are  the  lessons  learned  In  the 
overall  process  of  feeding  back  Information  to  Improve  the  diagnostic  capability. 

CEPS  data  feedback  will  conceptually  make  Improvement  possible  to  both  avionic 
system  testability  and  CEPS  performance. 

Fault  Isolation  Improvements  discovered  will  be  Integrated  Into  CITS  software,  T.O. 
fault  Isolation  procedures,  and  l-Level  TPS  T.O.s. 

CEPS  usefulness  is  directly  dependent  upon  a  user-friendly  system  that  Is  accepted 
by  the  maintenance  technicians. 

REFERENCES: 

1.  Anne  M.  Stanley,  ”6-1 B  Integrated  Diagnostics,”  NSIA  Conference  at 
Alexandria,  VA,  Feb.  1986. 

2.  Ken  Derbyshire,  ”6-1 B  On-Board  Fault  Detectlon/Fault  Isolation 
System,”  IEEE  AUTOTESTCON  1985. 

3.  Rockwell  International,  Mr.  Britt,  Autonetlcs  Program  Manager;  Anne 
Stanley,  lead  engineer  (714)  779-3379. 
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e.2  ID8S  -  FA 

NAME;  loss  -  FA  •  Feedback  Analysis 
YEAR: 

FUNCTION;  Collects  the  following  type  of  field  failure  and  diagnostic  data  from  all 
ADS  (3.2.1)  sites; 

-  Data  for  each  recorded  site  such  as  Identlfloatior^  of  the  equipment 
configuration  and  the  environment  In  which  It  has  been  operating. 

•  The  symptoms  observed  and  the  actual  faults  Isolated. 

•  Information  regarding  test  performance  at  each  site  Including  relevant 
performance  statistics. 

Once  this  collected  data  has  been  consolidated,  statistical  analysis  Is  performed  on 
the  data.  Summary  reports  are  prepared  which  provide  slte>to>8lte  performance 
differences  and  the  factors  such  as  environment  and  skill  levels  which  account  for 
these  differences. 

CAPACITY: 

CPU  T.ME: 

APPLICATION;  VLSI  P^  SUBSYS  SYSTEM 

ACQUISITION  PHASE:  CONCEPT  DEM/VAL  FSD  PRDCTN  DPLYMNT 

PUBLIC  DOMAIN?;  Y/N  (QFE) 

DESIGN  ENV: 

CIRCUIT  DESCRIPTION:  N/A 

USE  PREREQUISITE:  Provision  for  collecting  ADS  data  from  all  sites  of 
deployment. 

DEVELOPER:  Harris  Corporation  under  contract  from  the  US  Navy. 
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COMMENTS:  Th«  FA  conceptually  makes  Improvement  possible  to  both  weapon 
system  testability  and  IDSS  performance. 

The  global  FA  "learning*  loop  is  to  bo  distinguished  from  the  local  '^^k-:''nlng"  loop 
resident  at  each  site  which  updates  system  parameters  based  on  information 
derived  from  the  results  of  each  diagnostic  session.  This  local  loop  Is  a  quicker  but 
more  elementary  "learner"  and  Is  subject  to  more  rigid  update  time  requirements. 

REFERENCES; 

1.  Dr.  Bruce  J.  Rosenburg,  "The  Navy  Integrated  Diagnostic  Support 
System  •  System  Overview,  Architecture  and  Interfaces,"  IEEE 
AUTOTESTCON  1987. 

2.  Navy  Point  of  Contact 
NAVSEA  •  Code  CEL<DS 
Washington,  DC  20362-6101 
(202)  692-2035/2036 
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1.0  SCOPE 

1.1  PurpoM 

The  purpoee  of  this  appendix  Is  to  provide  guidance  on  the 
implementation  of  vertical  test  methods  as  part  of  the  diagnostic  design  process. 

1.2  Application 

This  appendix  Is  composed  of  the  following  sections; 

2.0  Overview 

3.0  Vertical  Test  Methods  and  Crfteria 
4.0  Dosign  Procedures  and  Documentation 

Application  of  this  guidance  will  ensure  that  vertical  testability  goals  are 
met. 

1.3  Definitions 
Vertical  Test  Methods: 

A  system  engineering  approach  for  establishing  and  maintaining 
compatible  test  methods  and  data  correlation  (I.  e.,  test  tolerances)  through  the 
various  echelons  of  weapon  system  development  and  support  (I.  e.,  development, 
production  (factory),  Intermediate  Level,  Depot  Level.  Organization  Level). 

Vertical  Commonality: 

Vertical  commonality  is  the  utilization  of  common  testing  resources 
between  levels  of  maintenance.  Implementation  of  the  vertical  commonality  concept 
manifests  Itself  In  "shrinking”  of  the  cone  of  tolerance  phenomena  and  the 
enhancement  of  testing  Integrity  between  levels  of  maintenance. 

2.0  OVERVIEW 

2.1  Testing  Proceea 

Testing  Is  necessary  to  successfully  design,  develop,  produce,  and 
maintain  an  operational  system.  Throughout  all  phases  of  a  program,  tests  are 
performed  to  assure  that  the  product,  as  designed  and  manufactured,  meets  the 
customer-prescribed  requirements.  Tests  to  verify  design  concepts,  Interface 
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capabilities,  and  performance  capabilities  are  conducted  during  the  Validation 
Phase  of  a  program  on  engineering  prototype  models  or  with  simulations  in  a 
computer<alded  engineering  environment.  Qualification  tests  are  then  performed  on 
full-scale  engineering  development  models  to  prove  that  the  unit,  as  designed  and 
fabricated,  meets  the  system  requirements  through  all  operating  conditions.  This 
normally  Includes  environmental  tests,  flight  tests,  reliability  teats,  and 
maintainability  demonatratlona  on  the  design  configuration.  Once  the  design  Is 
proven  and  the  unit  qualified  to  meet  its  operational  requirements,  the  system  is 
ready  for  production.  There  again,  testing  is  an  Important  criterion  to  assure  delivery 
of  failure-free  operational  systems.  Factory  test  normally  includes  receiving 
Inspection  on  incoming  components  and  subassemblies,  test  on  circuit  card 
assemblies  and  modules,  and  assembly  and/or  acceptance  test  on  deliverable  units. 
After  the  unit  Is  delivered  and  in  operation,  testing  Is  again  necessary  to  maintain 
the  system  free  from  operational  failures.  In  military  systems,  this  maintenance 
support  Is  typically  Implemented  at  three  operational  levels;  at  Organizational  Level, 
on  the  operational  vehicle;  In  an  Intermediate  Level  shop,  at  the  operating  site;  at  a 
permanently  located  Depot  Level  shop;  or,  In  some  Instances,  at  the  factory. 

Throughout  this  testing  process.  It  Is  imperative  that  an  Integrated 
approach  to  tost  and  maintenance  Is  effected.  In  order  to  ensure  that  CND  and 
RTOK  Instances  are  minimized  and  that  the  Integrity  of  the  testing  process  Is 
maintained. 

Design  verification  typically  Includes  bench  tests  on  functional  prototype 
models  conducted  by  engineers  or  sKilled  technicians  using  versatile,  highly 
interactive  test  equipment  which  is  easily  programmed  and  readily  changed.  These 
tests  are  performed  a  few  times,  the  results  are  recorded,  and  the  equipment 
reconfigured  to  obtain  additional  Information.  Since  the  objective  Is  to  determine  the 
suitability  of  the  design  for  the  operational  application,  much  of  this  test  and 
evaluation  Involves  simulation  of  the  operational  Interfaces  and  environment.  Test 
equipment  for  this  phase  normally  involves  a  combination  of  "off-the-shelf 
commercial  Instrumentation,  emulation  systems,  and  specially  designed  simulation 
and  monitoring  equipment. 

Factory  teat  requirements  begin  with  components  and  progress  to 
completed  assemblies.  The  objective  of  manufacturing  test  Is  to  eliminate  faulty 
components  and  manufacturing  defects  at  the  lowest  level  possible. 

In-circuit  tests  are  typically  performed  on  circuit  card  assemblies  because 
of  the  capability  of  this  type  of  testing  to  detect  manufacturing  defects  without 
application  of  power  and  loads  on  the  circuit  board.  This  is  especially  useful  for 
eliminating  incorrect  components  and  soldering  defects,  without  unduly  stressing 
components  on  the  cIrcuH  card  assembly. 
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ln<circuit  test,  however,  Is  Inadequate  for  detecting  all  manufacturing 
defects.  Functional  board  test  must,  therefore,  also  be  performed  with  the  unit 
operating  at,  or  near,  Its  performance  characteristics.  Functional  board  tests  also 
provide  acceptance  criteria  for  production  spares.  This  operation  involves 
application  of  stimulus  and  measurement  of  response  at  the  board  interface 
connector(s)  under  conditions  of  power  and  load,  which  should  "emulate"  as  closely 
as  possible  the  environment  the  subject  UUT  will  experience  in  the  next  higher 
assembly. 

Tests  on  the  next  higher  assembly  normally  include  manufacturing 
alignment  and  verification,  followed  by  a  burn-ln  and/or  vibration  cycle  and,  finally, 
an  acceptance  test,  in  preparation  for  delivery. 

Factory  tost  priorities  are  primarily  time-related.  They  must  be  available  In 
time  to  tost  Initial  deliveries;  they  must  be  performed  In  minimal  time  to  support 
throughput  and  production  rates;  and  they  must  bo  time  efficient  to  minimize  labor 
cost  and  expense  of  test  equipment. 

Maintenance  support  begins  with  a  malfunction  in  a  one-time  operational 
assembly,  confirms  or  detects  that  malfunction,  and  supports  isolation  of  the 
malfunction  to  a  replaceable,  failed  component.  The  standard  throe-level 
maintenance  system  begins  with  operational  maintenance  implemented  on  the  flight 
lino  In  an  operational  vehicle,  utilizing  bullt-ln  test  (BIT)  to  detect  and  perform  fault 
Isolation  for  black  boxes,  line  replacea'ble  units  (LRU)  or  weapon  replaceable 
assemblies  (WRA).  Repair  action  at  this  stage  consists  of  removal  and  replacement 
of  the  malfunctioning  assombi,-  and  successful  operation  of  BIT,  to  verify  that  the 
repair  rendered  the  vehicle  ready  for  service. 

The  malfunctioning  unit,  or  assembly.  Is  then  sent  to  the  Intermediate 
Level  shop,  where  H  Is  tested  to  determine  the  cause  of  the  maffurictlon  and  Isolate 
the  failure  to  a  shop  replaceable  unit  (SRU).  Repair  is  effected  by  removal  and 
replacement  of  the  faulty  SRU  and  successful  performance  of  the  LRU  to  verify  that 
It  is  ready  for  service.  The  faulty  SRU  Is  sent  to  a  Depot  Level  repair  facility,  where 
It,  In  turn,  Is  tested  to  determine  the  cause  of  the  malfunction.  Faulty  components 
are  removed  and  replaced,  and  the  SRU  Is  verified  ready  for  service  by  successful 
performance  test  at  the  Depot  or  sent  to  the  factory  for  test  and  repair. 

Maintenance  support  priorities  are  typically  efficiency  related,  with  the 
criteria  placed  on  fault  Isolation  and  elimination  of  unnecessary  testing  caused  by 
RTOKs,  CNDs,  and  fault  isolation  ambiguity  groups.  Another  problem  experienced 
by  maintenance  support  facilities  is  inadequate  configuration  management  or  delays 
between  development  of  equipment  design  changes  and  updated  test  capability. 
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CND  and  RTOK  problem  areas  can  exist  between  all  levels  of 
maintenance  from  lowest  to  filghest. 

0  Organizational  and  Intermediate  Level 

0  Intermediate  and  Depot  Level 

0  Depot  and  Factory  Level. 

Two  of  the  primary  contributors  to  RTOK  problems  are  test  tolerance 
problems  (I.  e.,  limit  selection)  and  teat  bed  Incompatibilities  (I.  e.,  environment  and 
performance  capabilities)  between  levels  of  maintenance. 

2.2  Cone  of  Tolerance  Overview 


All  electronic  circuits  can  be  regarded  as  an  approximation  of  some 
Idealized  mathematical  model.  The  model  for  a  linear  circuit  la  moat  often  a  transfer 
function.  The  model  for  a  digital  oirouit  la  a  Boolean  equation.  In  theory,  a  circuit 
could  be  specified  In  terms  of  the  mathematical  model  by  stating  the  equation  and 
the  allowable  deviation  over  a  specific  dynamic  range  of  amplitudes  and 
frequencies.  Consider,  for  example,  a  linear  circuit  designed  to  provide  some  given 
transfer  function.  A  test  of  this  circuit  might  consist  of  selecting  a  number  of  discrete 
frequency  signals,  measuring  the  gain  and  phase  shift,  calculating  actual  pole  and 
zero  locations,  and  comparing  these  to  the  mathematical  model.  In  practice,  this 
Idealized  approach  to  specifying  and  testing  circuit  performance  Is  not  often  used. 
The  reasons  are  quite  pragmatic:  real  oircults  always  exhibit  nonllnearltles  and 
random  noise;  power  sources  are  never  pure  DC;  and  depending  on  the  available 
Instrumentation,  some  characteristics  are  more  easily  measured  than  others. 
Consequently,  circuit  performance  requirements  must  often  be  specified  In  terms  of 
both  circuit  component  tolerances  and  very  speolfLo  test  conditions.  Tight 
restrictions  must  be  placed  on  power  supply  accuracy  and  regulation  and  precise 
stimulus,  and  measurement  values  must  also  be  specified. 

In  the  design  of  a  weapon  system,  a  great  deal  of  time  Is  usually  spent  In 
system  Integration  and  checkout.  Typically,  this  h  done  by  setting  up  a  "hot 
mockup"  of  the  system  and  interconnecting  the  Individual  assemblies.  With  this 
situation.  It  Is  only  natural  that  much  of  the  engineering  effort  will  be  devoted  to 
getting  the  weapon  system  to  pass  system-level  tests.  As  a  result,  subsystem  (I.  e., 
LRU/SRU  and  lower  assembly)  test  specifications  and  test  procedures  are  often 
neglected.  Generally,  they  will  be  incomplete  and  Inaccurate.  Tolerances  on  the 
test  specifications  may  be  unrealistic.  When  there  Is  not  sufficient  time  to  make 
accurate  tolerance  calculations,  the  tendency  Is  to  err  In  the  direction  of  tighter 
tolerances  to  ensure  that  an  assembly  that  meets  these  tolerances  will  work  in  the 
next  higher  assembly.  Too  often  these  excessively  tight  tolerances  are  propagated 
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into  the  depot  and  field  test  procedures,  giving  rise  to  unnecessary  ATE 
compatibility  problems. 

In  some  cases,  tight  tolerances  on  power  supply  and  instrument 
accuracies  are  an  attempt  to  ensure  that  the  test  Instruments  are  as  good  as.  or 
better  than,  the  ones  used  by  the  circuit  designer  In  engineering  tests  on 
breadboard  or  preproduction  circuits  back  at  t!ie  factory.  Tolerances  should  always 
be  expressed  In  absolute  terms  and  not  relative  to  a  particular  test  instrument. 

In  specifying  circuit  tolerances,  there  Is  no  substitute  for  good  analysis 
which  is  supported  by  sufficient  laboratory  testing.  The  designer  should  know 
precisely  how  variation  In  anv  component  will  affect  the  operation  of  the  circuit.  The 
system  tolerance  should  be  the  basis  for  assignino  an  error  budget  to  each  system 
and,  hence,  to  each  reolaoeabje  assembly  In  the  subsystem. 

Many  engineers  are  familiar  with  the  systematic  approach  to  allocation  of 
reliability  requirements.  A  corresponding  approach  to  allocation  of  error  budget  may 
be  of  some  value.  Of  course,  the  calculations  and  derivation  of  mathematical 
models  need  not  be  ae  well  documented  or  as  formalized  as  the  reliability  alloca* 
tions.  Formalized  documentation  requirements  are  only  necessary  when  there  Is  an 
Interface  between  technical  dlscipllnes<*as  there  often  Is  between  the  reliability^ 
maintainability,  and  design  disoipllnea.  What  is  needed  Is  a  system  approach, 
without  the  system  approach’s  paperwork. 

In  the  areas  of  tolerance  calculation  and  sensitivity  analysis,  one  should 
consider,  as  an  aid,  the  use  of  computer-aided  techniques.  An  advantage  of  these 
techniques  Is  the  number  of  calculations  that  can  be  completed  In  a  relatively  short 
time.  These  calculations,  however,  are  only  as  good  as  the  mathematical  model 
used  In  the  analysis  program.  The  user  must  be  fully  aware  of  limitations  in 
simulation  programs  used  for  this  purpose. 

Thus  equipment  designers  must  establish  test  tolerance  values  at  all 
levels  of  test,  with  tighter  tolerances  at  the  Factory  Level,  increasing  as  shown  In  the 
Cone  of  Tolerance  In  Figure  1 .  This  will  preclude  ”bounelng"  the  UUT  back  and 
forth  between  levels  of  repair  (I.  e.,  RTOK  problem).  If  the  designer  does  not 
consider  the  tolerance  cone  in  development,  tighter  test  requirements  will  result  in 
Organizational  and  Intermediate  Level  overdesign  and  Increased  acquisition  costs 
for  the  UUT. 
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nOURE  1 .  CONE  OF  TOLERANCE 


3.0  VERTICAL  TEST  METHODS  AND  CRITERIA 

3.1  Fsctory/DoBiQn  Envlronmont 

3.1.1  Ovorvlow 

The  mission  of  the  factory  Is  to  design,  develop,  and  performance  verify 
UUT  for  production  applications.  The  primary  testing  mission  Is  to  ensure  that  a 
"good"  product  leaves  the  factory.  A  "good"  product  Is  defined  as  an  end  Item  which 
meets  its  performance  verification  goals. 

In  order  to  achieve  this  goal,  It  Is  Important  to  establish  proper  test  limits 
for  static  and  dynamic  tests.  If  the  tolerance  bands  are  made  too  loose,  it  is  possible 
to  pass  a  defective  UUT,  and  If  the  tolerance  bands  are  made  too  tight.  It  Is  possible 
to  fall  a  good  one. 
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Typically,  last  program  aat  aoftwara  Implamanted  on  factory  test 
equipment  is  the  primary  vehicle  for  performance  verifying  and  fault  Isolating 
production  UUTa.  The  following  provides  an  overview  of  typical  design  analysis 
procedures  used  to  derive  UUT  performance  specification  iimits  in  a  factory  environ¬ 
ment. 


3.1 .2  Typical  Oealgn  Analysis  Procedure 

There  are  many  priorities  considered  by  the  eiectronlo  design  engineer 
during  the  design  phase  of  a  product.  Many  product  features  are  considered: 
performance,  development  and  product  cost,  reliability,  testability,  produclblllty, 
maintainability,  size,  weight,  power,  and  efficiency.  The  pertinent  priority  considered 
here  Is  performanoe»speoifloally.  the  limits  that  are  used  to  guarantee  product 
performance  through  teat. 

During  the  development  of  an  eiectronlo  product,  the  design  engineer 
typically  uses  a  worst-case  design  analysis  procedure  because  it  is  a  safe  and 
reliable  approach  and  Is  the  easiest  analysis  to  perform.  This  analysis  virtually 
guarantees  a  100%  yield  during  any  type  of  performance  test.  If  worst-case  tech¬ 
niques  do  not  fulfill  ail  of  the  product  requirements,  then  oompromlaes  are  usually 
made  that  result  In  a  change  to  the  design  or  a  more  realistic  analysis  approach  Is 
used  to  determine  output  performance  limits. 

A  more  realistic  design  approach  can  usually  be  Implemented  by  using  a 
statistical  approach,  which  is  a  more  difficult  analysis  than  worst-case.  The  most 
common  statistical  analysis  Is  termed  Root  Sum  of  Squares  (RSS).  There  are  other 
statistical  analyses,  such  as  Monte  Carlo,  that  will  produce  virtually  the  same  results 
as  RSS,  when  the  number  of  trials  becomes  larger.  Statistical  iimits  place  tighter 
tolerances  on  the  outputs  and  result  in  less  safety  margin  and  less  yield  In 
production. 

If  worst-case  and  RSS  analyses  do  not  meet  the  design  specifications  and 
requirements,  then  a  systematic  analysis  Is  normally  invoked.  This  analysis  uses 
predictable  characteristics,  such  as  component  or  power  supply  tracking.  Usually,  a 
systematic  analysis  approach  Is  a  subset  of  worst-case  or  RSS. 

In  virtually  alt  designs,  a  combination  of  these  analysis  techniques  Is  used. 
Naturally,  worst-case  Is  attempted  first  because  of  its  preferred  features,  followed  by 
RSS,  and  then,  as  a  last  resort,  by  systematic. 

A  brief  overview  of  typical  test  limit  calculations  In  the  factory,  utilizing 
worst-case  and  statistical  tolerance  techniques,  Is  discussed  In  the  following 
paragraphs. 
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3.1 .2.1  Wortt-CtM  Analytit 

If  worat'oaaa  analyaaa  are  usad  to  astabllah  paas/fall  test  limits  for  a  UUT, 
then  K  Is  possible  to  have  a  failed  or  defective  component  and  still  pass  test.  This  Is 
true  beosuse  It  is  extremely  unlikely  that  a  worst-case  limit  can  be  experienced  In 
normal  situations.  Although  this  may  not  bo  detrimental  In  the  immediate  test 
environment,  It  oould  render  the  UUT  Inoperative,  or  significantly  degraded,  In  actual 
operation. 


For  worst-oase  analysis,  the  maximum  {■¥)  worst-case  tolerance  can  be 
found  by  analyzing  a  circuit's  transfer  function  and  ascertaining  which  oomponents 
In  the  numerator  should  be  at  their  maxirrum  values  and  which  components  In  the 
numerator  should  be  at  their  minimum  values.  A  similar  technique  oan  be  utilized  to 
calculate  the  minimum  (•)  worst-case  tolerance. 

For  analyses  Involving  timing  analysis,  maximum  and  minimum  worst- 
oase  tolerances  are  oaloulated  utilizing  summing  techniques  for  each  component  In 
the  subject  timing  chain. 

3.1 .2.2  Root  Sum  of  Squares  (RSS)  Statlatloal  Toleranolng 

Although  RSS  analysis  predicts  a  yield  of  09,7%  and  a  Gaussian  output 
distribution,  It  Is  based  on  the  condition  that  all  contributing  oomponents  possess 
Gaussian  (normal)  distributions  over  their  complete  specified  range,  As  an 
example,  a  10%,  100  ohm  resistor  Is  expected  to  possess  a  distribution  as  shown 
In  Figure  2.  This  Is  hardly  ever  the  case  in  actual  practice,  however.  Most  often, 
the  distributions  are  quasl-Qausslan  and  "skewed.”  What  causes  this  condition  Is 
that  the  manufacturer  of  the  oomponents  desires  a  high  yield,  and  the  mean  of  the 
distribution  will  vary  from  lot  to  lot.  Consequently,  "skewed*  distributions  are  more 
realistic  distributions  to  expect  In  a  manufacturing  environment. 
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nOURE  2.  IDEAL  DISTRIBUTION  FOR  A  100  i  10  OHM  RESISTOR 

If  'sktwAd*  ditttrlbutlone  Indtttd  rcalittio,  how  dots  tho  factory  justify 
RSS  analyalt? 

In  tha  world  of  ttatlstloa,  tha  Cantral  Limit  Thaoram  pradicta  that  no  mattar 
what  tha  Individual  distribution  of  tha  contributing  oomponants,  tha  rasulting 
distribution  of  tha  subjact  parformance  paramatar  approaches  Qausslan 
charactarlstios  as  tha  number  of  samples  baoomao  large.  However,  real-world 
acquisition  seansrioa  somatimas  pisy  havoc  with  tha  Cantral  Limit  Thaotam's 
ganarallzation.  QuKa  often,  military  systems  are  subject  to  short  production  runs  and 
”on-agaln,  off-again”  proouramants,  which  are  spread  out  over  many  ysors  and 
utilize  many  different  second-source  suppliers  Unless  qualified,  soraanad 
components  sre  utilized,  it  is  possible  that  tha  performance  characteristics  of  tha 
rasulting  and  Item  will  deviate  from  the  "nominal*  performance  characteristic 
specifications. 

That  Is,  tha  ”raal  life”  nominal  value,  which  Is  manifested  In  the  subject 
end  Item,  will  be  ■skewed"  significantly  to  tha  right  or  left  of  tha  "normal"  nominal 
value. 


Where  component  tolerances  are  controlled  and  maintained,  RSS 
techniques  at  the  factory  can  be  utilized  to  derive  statistically  sound  limits  for  a  UUT, 
when  applied  In  concert  with  ATE  Instrumentation  and  swItchlnQ  characteristic  data. 
For  RSS  analysis,  the  maximum  output  for  a  subject  performance  parameter  can  be 
found  by  calculating  the  change  to  the  performance  parameter  (P^)  due  to  a  change 
In  each  component  value  (C^)  of  the  circuit,  squaring  each  term,  and  taking  the 
square  root  of  the  resulting  expression. 
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Mathamatically  speaking,  RSS  can  be  calculated  as  follows; 


There  are  other,  leas  laborious  methods,  that  can  be  used  for  RSS 
analysis,  such  as  a  method  Involving  partial  derivatives.  This  method  Is  very  easily 
performed  with  available  computer-aided  design  programs,  such  as  SPICE.  Utilizing 
the  circuit  design  data  base,  each  component  circuit  value  Is  edited  to  Its  worst-oase 
maximum  value,  a  circuit  simulation  run  of  the  "adapted”  circuit,  and  the  resulting 
output  changes  recorded.  This  technique  Is  done  for  each  circuit  component  which 
has  an  affect  on  the  subject  output  parameter  in  question.  Then  utilizing  a  "canned" 
software  routine,  eaoh  change  Is  squared,  summed  with  the  other  changes,  and  the 
square  root  oalculated  to  yield  the  resulting  RSS  change. 

When  utilizing  this  procedure,  all  terms  except  the  component  In  question 
assume  their  nominal  value,  while  the  one  In  question  assumes  its  worst-oase  value. 
Nominal  circuit  parameter  tolerances  are  derived  for  a  UUT  by  running  a  good  circuit 
simulation  with  all  components  set  to  their  "nominal”  values.  The  results  of  an  RSS 
analysis  yields  a  distribution  that  Is  Qausslan  in  form  and  predicts  that  99.7%  of  the 
performance  parameter  values  for  a  "good*  UUT  will  fall  within  the  Qausslan  3 
limits.  A  similar  type  of  analysis  can  also  be  performed  for  the  negative  extreme. 

3.1.3  PaotoryATB 

It  Is  Important  to  note  that  the  factory  test  environment  differs  drastically 
from  the  field  environment.  Testing  in  the  factory  Is  primarily  addressed  from  a 
"bottom  up*  point  of  view.  The  spectrum  of  factory  ATE  varies  from:  component 
test,  bare  board  test,  loaded  board,  LRU/assembly  test,  and  In-olroult  test  to 
functional  board  test,  "hot  mocKup*  testing,  or  certification  testing  In  the  next  higher 
assembly. 


The  factory  test  environment  is  exacting  and  comprehensive.  Factory 
testing  Is  orchestrated  to  fault  detect  and  fault  Isolate  a  broad  cross  section  of 
failures,  such  as  shorts,  opens,  solder  splashes,  components  out  of  tolerance, 
components  Inserted  Incorrectly,  wrong  value  of  components  utilized,  etc.  Typically, 
once  the  subject  end  Item  Is  tested  utilizing  factory  ATE,  It  Is  Integrated  Into  the 
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dtlivtrabi*  product  (I.  •„  oomputor,  radar,  ato.)  for  final  functional  tasting.  This 
Integration  prooass  asauras  that  tha  whole  is  equal  to  the  sum  of  the  parts  and  that 
the  system  functions  to  performance  specifications.  If  the  system  dose  not  meet 
performance  requirements,  a  combination  of  manual,  semiautomatic,  and  automatic 
testing  Is  utilized  to  ascertain  which  system  component  Is  the  cause  of  system 
failure.  The  subject  system  component  (I.  e.,  SRU,  assembly,  LRU)  Is  then  sent 
back  to  the  appropriate  level  of  test  In  the  factory  to  ascertain  failure  resolution 
wKhln  the  subject  end  Item. 

If  It  la  determined  that  the  subject  end  item  passes  Its  ATE  functional  test 
and  fails  system  Integration  testing,  an  analysis  is  typically  performed  to  ascertain 
what  changes  are  required  to  the  factory  ATE  and/or  TPS  to  eliminate,  or  minimize, 
the  RTOK  problem  at  the  factory.  Typically,  primary  *flxes”  Involve; 

0  ModHIcatlon  to  test  limits,  to  reflect  more  accurately  performance  limits 
required  In  the  next  higher  assembly 

0  Interface  device  loade  and  circuitry,  to  "emulate"  more  accurately  the 
next  higher  assembly  in  the  ATE  functional  test  test  bed. 

This  data  then  la  fed  back  to  the  manufacturing  test  group  to  ensure  that 
the  factory  ATE/TPS  are  updated  to  ensure  Increased  yield  In  the  manufacturing 
test  process.  The  repository  for  this  Information  is  embodied  wNhln  factory  ATE  and 
TPS  configuration  base  lines  and  the  associated  factory  system  acceptance  test 
procedures.  Typically,  this  data  Is  not  formally  configuration  managed,  per  MIL* 
STD*480  procedures,  but  maintained  as  engineering  Information  released  by  test 
engineering  to  manufaotuilng  test 

This  data  Is  typically  not  a  contractual  deliverable. 

3.2  Peotory  and  OKBrr)/l-/D-Level  Interfaoe 

Parametric  testing,  utilizing  the  ATE,  is  the  prevalent  method  used  to 
evaluate  performance  of  electronic  assemblies  during  their  manufacture  at  the 
factory  and  during  the  operations  phase  of  their  lifetime  at  the  Depot  and 
Intermediate  Levels  of  maintenance. 

The  most  common  method  of  parametric  testing  is  to  construct  an 
emulation  of  the  next  higher  assembly,  consisting  of  the  UUT,  the  ATE,  and  an 
Interconnection  Device  (ID).  F.mulatlon  of  prime  system  signals  and  basic 
measurement  capability  are  provided  by  the  ATE.  The  ID  is  generally  passive,  but 
occasionally  is  used  to  modify,  or  buffer,  signal  patho  In  some  manner.  Assuming 
that  the  test  designer  knows  the  level  of  performance  which  Is  required  of  the  UUT 
to  allow  the  prime  to  meet  Its  performance  requirements,  a  set  of  test  limits  Is 
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par  tht  diaoiisslon  In  tha  pravioua  sactlon.  Thasa  limits  must  also  taka  Into  con- 
sldaratlon  tha  uncartalntlas  prasant  In  tha  stlmulus/maasuramant  procass,  as 
lllustratad  In  Flgura  3,  If  wa  ara  to  guarantaa  corralatlon  batwaan  tha  ATE  tast  and 
oparatlon  in  tha  prlma  systam. 


PERFORMANCE  REQUIRED 
I  INSYSTEM  ^  ^ 

-  TOLERANCE  NOMINAL  +  TOLERANCE 


u _ 

_ ^1 

I 

IHHI 

_ ^ 

f  TEST  LIMITS 

MEASUREMENT/^ 

UNCERTAINTY 


RGURE  3.  TEST  LIMITS  MUST  BE  SET  TO  COMPENSATE 
FOR  MEASUREMENT  UNCERTAINTIES 


Tolaranoas  for  tasting  ara  commonly  caloulatad  as  a  Root  Sum  of  Squaras 
(R8S),  whan  tha  arror  souroas  ara  statlstleally  Indapandant  and  normally  distrlbutad. 

For  axampla: 

whara 

a  UUT  output  tolaranoa  as  caloulatad  utilizing  sensitivity  analysis, 

^  modulatad  by  raal-llfa  axparlanoa,  and  as  documantsd  In  tha 

appropiiata  UUT  parformanca  spaoHloatlon 

a^  -  Tast  systam  arror,  Including  maasuramant  arror  and  tha  affaot  of  tast 
systam  nolsa  soureaa 
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-  Error  rofi«ot«d  at  UUT  output  due  to  stimulus  unoartainty 


Tha  tarm  a,  can  bo  raducad  by  programming  taohniquas  which  allmlnata 
tha  long-tarm  affacts  of  componant  aging,  tharmal  drift,  and  othar  factors  which 
remain  constant,  or  assantlally  constant,  ovar  tha  ralativaly  short  tima  that  It  takas  to 
axacuto  a  tast  on  tha  support  system.  Similarly,  tha  maasuramant  arror  a^  can  be 
reduced.  If  tha  tast  system  Includes  a  calibration  rafaranca  for  tha  maasuramant 
Instrument,  long-tarm  drift  In  maasuramant  accuracy  can  be  eliminated  by 
approphata  calculations  at  'ha  tima  of  tast  execution.  Transmission  line  affacra  ean 
-ilsQ  be  raducad.  bv  taking  >rtc  account  tha  Insertion  of  losses  and  Imoadanoa 
-nismatchiijor  reflection  coefficients  along  the  transmission  line  between  tha  UUT 
-tnd  ATE  stimulus  and  maasuramant  davicas. 


These  stimulus  and  maasuramant  parameters,  for  tha  most  part,  are  not 
known  until  tha  Depot  Laval  ATE  to  be  used  has  bean  daflnad:  This  definition  does 
not  always  occur  in  tha  proper  time  frame.  -In  addition,  tha  parameters  for  tha 
factory  ATE  are  not  always  charaotarlzad  and  documantad  for  depot  and  field  uses. 
Tha  rasuH  Is  often  evidant  In  the  form  of  nonootimliad  tast  limit  assignments  and  as 
RTQK  problems  between  tha  factory  and  tha  field. 

A  potential  problem  exists  of  nominal  value  skew  whan  circuit  componant 
tolerances  are  not  controlled  In  tha  factory  design  environment.  This  anomalous 
situation  can  potentially  causa  RTOK  problems  In  tha  factory  for  and  Items  which 
have  tasted  "bad*  In  tha  field  due  to  a  combination  of  factors:  'nominal  circuit 
tolerance  skew”  and  tha  'maasuramant  unoartainty”  of  Depot  Laval  ATE  (sea  Figure 
4).  A  similar  condition  can  alao  exist  between  tha  Depot-  and  Intannadlata-Lavals  of 
Tast. 


Thus  appropriate  attention  to  detail  with  respect  to  tha  sotting  of  circuit 
tolaranoas  and  the  control  of  these  tolerances,  via  tha  aequialtion  and  spare  parts 
procurement  process.  Is  essential.  In  order  to  assure  that  a  'nominal  value  skewing" 
problem  doaa  not  manifest  Itself  as  a  RTOK  probiam  In  tha  UUT  maintenance  chain. 

If  all  maintenance  acttvftlas  associated  with  tha  UUT  are  Included,  a  conic 
tast  tolerance  envelope  results,  as  previously  depicted  In  Figure  1.  The  base 
dimension  of  the  cone  represents  the  level  of  performance  required  in  the  system  In 
Its  operational  environment.  This  tolerance  value  is  typically  the  accuracy  required 
of  Organizational  Level  BIT  atimulus/measurement  devices  to  certify  UUTs  Ready 
for  Issue  (RFI)  at  the  platform  level.  The  slope  of  the  cone  Is  a  composite  of  the  test 
uncertainties  at  all  levels  of  test.  The  height  of  the  cone  Is  defined  by  the  number  of 
different  maintenance  levels  at  which  that  parameter  Is  tested.  Note  that  these 
factors  act  to  define  the  level  of  accuracy  required  of  the  ATE  at  each  level  of  main- 
lanftnat- 
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"Toltranct  cona  budgeting"  la  an  accepted  method  of  distributing  test 
limits  across  the  various  uncertainty  factors  associated  with  the  manufacture  and 
maintenance  of  electronic  assemblies.  The  intent  is  to  define  test  limits  at  each  test 
level,  so  that  adequate  margins  for  test  equipment  performance  and  prime  product 
performance  are  allowed.  Prouerlv  appiled.  tolerance  cone  budgeting  results  In 
good  correlation  between  test  results  at  each  maintenance  level  and,  therefore, 
minimizes  nonveiified  failures  with  their  attendant  cost  and  lost  time  Implications. 


NORMAL  TEST  UMTS 
NOMINAL 
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POSnNt 


-  AOJucnD  nsr  uuns  - 

TS 

ACCOUNT  na  iflceuMBaNT 
UNOSRTAMTr 

Kt 

DSKTUML 


ND  NOUMN.  TOT  UMTS  AT  TMK  rABTONT  AND  I 

or  oiNT  An  —  mcK  oonmtwn  at  nanm 


Failure  to  perform  a  rigorous  analysis  of  the  affects  of  test  tolerance  build¬ 
up  often  results  In  test  limits  being  arbitrarily  assigned  on  the  basis  of  ATE/dlagnostIo 
element  capabilities,  rather  than  on  the  basis  of  correlation  at  the  next  level  of  test. 
This  will  Invariably  resuH  In  one  of  three  problems; 

1 .  A  failure  of  the  prime  system  to  perform  to  specification,  even  when  all 
Individual  devices  test  "good" 

2.  An  excessive  number  of  devices  In  the  pipeline,  due  to  UUT  which  test 
"good"  at  one  level,  but  "bad"  at  the  next  maintenance  level  (RTOK) 


3.  Unnecessary  repair  actions  caused  by  test  limits  which  are  excessively 
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Ocourrtnot  of  any  on*  of  tho  above  altuatlona  will  result  in  axoeaaive 
maintenance  activity  and  probably  will  Impact  prime  ayatem  availability  or 
performance,  as  well. 

If  tolerance  cone  budgeting  ie  to  succeed  ae  a  testing  strategy,  a  data 
base  of  controlled  parameters  must  be  defined  and  characterized  at  each  level  of 
maintenance  for  use  at  other  maintenance  levels  in  setting  their  test  limits. 

3.3  Generic  Data  Base  Requlrementa 

Based  on  the  discussions  In  the  previous  sections,  tabulated  below  are 
generic  data  base  requlrementa  for  diagnostic  ATE,  which  must  be  data  based  to 
resolve  vertical  test  and  RTOK  problems  between  the  Factory  and 
Intermediate/Depot  Levels  of  test  and  which,  when  controlled,  ensure  traceability  of 
test  requirements  from  the  factory: 

0  Component  tolerances  (%)  for  all  components  which  contribute  to  or 
affect  the  subject  performance  parameter  tolerance 

0  ATE  stimulus  stability  and  accuracy  for  each  performance 
parameter  test 

0  ATE  response  stability  and  accuracy  for  each  performance 
parameter  test 

0  Stimulus  swHchIng  uncertainty  (path  resistance  and  distributed  shunt 
oapacitanoe)  for  each  perfomtanoe  parameter  test 

0  Test  accuracy  ratio  achieved  for  each  performance  test,  based  on  the 
factors  Identified. 

As  a  rule  of  thumb,  a  test  accuracy  ratio  of  greater  or  equal  to  three-to- 
one  Is  typically  maintained  between  the  test  measurement  accuracy  and  the  test 
requirement  to  ensure  test  measurement  integrity. 

3.4  Vertical  Testability  Method  AltemaHvee 

Besides  tolerance  cone  budgeting  and  the  maintenance  and  traceability  of 
controlled  parameters,  other  criteria  and  methods  may  be  employed  to  ensure 
vertical  testability  across  maintenance  levels.  Two  such  methods  which  have,  or  are 
starting  to  have,  wide-spread  application  are: 

0  Employment  of  common  ATE  between  maintenanco  levels 
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0  ATE  emulation. 

A  brief  disouaslon  of  each  of  these  vertical  test  methods  Is  given  In  the 
following  paragraphs. 

3.4.1  Common  ATE 

One  approach  to  reducing  the  tolerance  cone  "bulld'up*  problem  Is  the 
utilization  of  common  functional  ATE  and  teat  program  seta  In  both  the  factory  and 
the  field  (vertical  commonality).  The  approach  Is  predicated  on  the  assumption  that 
the  same  functional  ATE  that  la  used  In  tandem  with  other  factory  ATE  (I.  e..  In- 
circuit.  component,  etc.)  can  also  be  utilized  to  support  the  Depot  and  Intermediate 
Level  testing  functions.  This  testing  concept  reduces  the  "uncertainty*  of  test  to 
Include  only  the  calibration  variation  of  the  ATE,  thus  minimizing  the  need  to  budget 
test  equipment  performance  at  each  maintenance  level-ln  effect,  "shrinking  the 
tolerance  cone." 

This  approach  la  not  without  its  drawbacks,  however.  The  manufacture 
teat,  field  test,  and  depot  repair  environments  are  considerably  different,  and  an 
efficient  ATE  system  for  one  may  not  prove  to  be  efficient  for  others,  unlesa  oropertv 
manaoed  and/or  adapted.  Some  differences  between  these  two  environments  are: 

0  Manufacturing  final  acceptance  testa  using  ATE  are  typically  designed 
to  test  one  type  of  product,  to  test  It  rapidly,  and  to  diagnose  to  a 
parameter  level  only.  Fault  isolation  and  repair  are  typically  done 

elsewhere. 

0  Reid  "black  box"  level  teets  using  ATE  ore  typically  required  to  support 
a  quantity  of  different  types  of  UUT  which  arrive  at  irregular  intervals. 
Fault  Isolation  to  the  replaceable  assembly  level  and  repair 
verification/alignment  are  performed  on  the  ATE  by  relatively  low-skill- 
level  operators.  Support  of  the  ATE  Itself  is  limited  by  local  shop 
resources  and  training. 

0  Depot  ATE  Is  required  to  handle  many  different  types  of  assemblies 
arriving  In  small  quantities.  Repair  Is  to  the  defective  component  level. 
Repaired  UUT  must  be  verified  to  a  high  degree  of  confidence,  since 
the  prime  system  Is  not  available  to  validate  the  repair  action. 
Normally,  the  repaired  UUT  becomes  a  spare. 

These  differences,  coupled  with  the  thrust  to  perform  more  maintenance 
using  ATE,  make  It  important  to  develop  ATE  hardware  and  software  which  Is 
appropriate  for  use  at  all  levels  of  maintenance.  Merely  specifying  "modular* 
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sysUms  Is  not  adsquats.  Thought  must  bs  given  to  how  the  equipment  Is  to  be 
used  and  by  whom.  Only  then  will  benefits  accrue  from  modular  systems  ar- 
ohHecturs. 


While  factory  and  maintenance  support  have  different  operating 
environments,  they  have  many  common  reoulrements  and  oblectlvet.  Final 
acceptance  test  In  the  factory  la  an  equivalent  requirement  to  operational 
performance  verification  in  the  field  maintenance  support  environment. 
Manufacturing  test  at  the  factory  must  Include  capability  for  fauK  detection  and  fault 
Isolation,  which  Is  the  primary  objective  of  field  testing. 

It  Is  reasonable,  therefore,  to  consider  common  test  capabilities  (I.  e., 
vertical  commonality)  to  support  both  factory  and  maintenance  support  requirements 
at  assembly  and  subassembly  levels. 

The  concept  of  vertical  commonality  Is  (the  Implementation  of)  common 
requirements  In  the  factory,  field,  and  depot  predicated  on  a  common  automatic  test 
system  architecture,  consisting  of  common  bus  structures,  stimulus  generators, 
response  monitors,  switching  devices.  Interface  devices,  software  operating  system 
(SOS),  and  test  program  sets  (TPS). 

The  primary  advantage  of  this  approach  Is  the  Inherent  built-in  vertical  and 
horizontal  compatibility.  The  use  of  the  same  instruments  to  perform  the  tests,  the 
same  software  to  control  the  tests,  the  same  Interface  pins,  the  same  bus  structures 
to  tie  the  modular  components  together,  the  same  mechanical  fixtures  to  implement 
the  tests,  and  the  same  criteria  to  evaluate  the  test  at  the  Factory,  Field,  and  Depot 
Levels  eliminates  many  of  the  unnecessary  retests  and  ambiguous  determinations 
which  Impede  throughput  in  the  factory  and  maintenance  support  facilities. 

Common  teat  systems  for  Factory,  Field,  and  Depot  Levels  of 
maintenance  provide  many  benefits  for  both  the  supplier  and  the  customer.  The 
overall  program  cost  is  reduced  by  one-time  development  of  a  TPS  to  serve  both 
requirements.  Common  tests  at  each  level  produce  consistent  results  by  reducing 
unnecessary  testing  (I.  e.,  HTOK)  of  operational  units.  Use  of  common  test  systems 
In  the  factory  provides  the  supplier  with  a  local  proving  ground  for  TPS 
effectiveness,  resulting  In  a  proven  TPS  which  can  be  delivered  to  the  customer  in 
time  to  support  initial  system  deliveries  and  negating  the  requirement  for  contractor 
mointenanee.  Another  Inherent  advantage  is  configuration  management,  based  on 
the  fact  that  units  delivered  from  the  factory  must  be  tested  on  the  same  equipment 
and  with  the  same  test  programs  used  for  maintenance  support.  Changes  in  the 
prime  equipment,  therefore,  must  have  corresponding  changes  Incorporated  Into  the 
test  program  sets  before  the  units  can  be  delivered,  thus  making  test  program  set 
updates  concurrent  with  prime  equipment  configuration  changes. 
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The  net  result  la  a  product  delivered  with  a  proven  support  capability, 
available  concurrently  with  the  program  needs,  and  maintained  current  with 
configuration  changes  by  factory  acceptance  test  requirements.  The  customer  Is 
benefited  by  a  better  supported  product,  while  the  supplier  gains  a  reputation  for 
product  support,  which  enhances  future  business  opportunities.  Vertical 
commonality  provides  the  capability  to  test  during  design  to  prove  that  the  product 
works;  to  test  during  qualification  testing,  to  prove  that  It  works  under  all  conditions; 
to  test  during  production,  to  prove  that  It  works  with  all  combinations;  and  to  test 
during  support,  to  prove  that  the  product  works  throughout  Its  entire  service  Ilfs. 

3,4.2  ATE  Emulation 

Another  approach  to  vertical  testability  has  been  to  adopt  the  approach  of 
"ATE  emulation."  Emulation  Is  an  approach  by  which  the  I/O  Interface  of  an  ATE 
system  Is  functionally  replicated,  on  a  test-by-test  basis,  by  a  substitute  system 
which  utilizes  a  combination  of  hardware  and  software.  This  approach  Is  typically 
utilized  when  the  sunk  cost  Investment  in  test  program  set  software  Is  extensive  on 
an  obsolete,  or  soon  to  be  obsolete,  piece  of  equipment  and  new,  replacement  ATE 
Is  to  be  procured,  or  when  a  Depot-  or  Intermediate-Level  ATE  TPS  Is  developed, 
utilizing  factory  "source"  programs. 

Figure  5  depicts  the  classioal  approach  to  achieving  ATE  emulation, 
utilizing  the  concept  of  hardware  reconfiguration.  Vertical  transportabllHy  between 
factory  ATE  and  depot  ATE  Is  dependent  on  a  number  of  factors,  some  of  which 

are: 


o  Performance  capability  of  "functionally  equivalent"  Insrumentatlon  (I. 
e.,  rangee,  accuracy,  stability,  granularity,  etc.) 

o  Performance  oompatlbllHy  of  switching  systems  (I.  e.,  path  resistance, 
shunt  oapacHanoe,  off-set  voltage,  noise,  etc.) 

0  Calibration  accuracy  differences  between  Instruments. 
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Thus  the  classical  ATE  emulation  concept  minimizes,  but  does  not  totally 
eliminate,  "measurement  uncertainty"  between  the  factory  ATE  and  the  emulation 
ATE. 


An  alternative  approach  to  hardware  reconfiguration  is  software 
reconfiguration,  utilizing  concepts  such  as  pin  electronics  (PE)  as  the  emulation 
vehicle  (see  Figure  6).  Pin  electronics  employs  high-speed  D/A  and  A/D  technology 
behind  each  UUT  I/O  pin.  No  electromechanical  switching  Is  employed.  Each  PE 
channel  Is  a  "virtual  instrument"  In  disguise  which,  via  software  control,  can  emulate, 
up  to  approximately  25  MHz,  any  electrical  interface  signal  and  propagation  delay. 
Any  ATE  anomalles/characterlstics  of  the  factory  ATE  can  be  emulated  by  the  PE 
ATE.  This  emulation  approach  can  be  utilized  over  a  broad  spectrum  of 
applications.  ITie  ramifications,  from  a  vertical  testing  compatibility  point  of  view,  are 
encouraging: 

0  Because  of  the  employment  of  high-speed/hlghly  granular  D/A  and  A/D 
technology,  measurement  and  stimulus  uncertainty  Is  minimized 

0  The  absence  of  a  switching  function  from  the  PE  system  architecture 
eliminates  stimulus/measurement  switching  uncertainly  from  testing 
tolerance  limit  calculation 
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0  Calibration  accuracy  diffarances  In  tha  limit  bacoma  the  primary  drivars 
of  maaaurament  uncartainty  batween  tha  original  ATE  (factory)  and 
amulation  ATE  (dapot). 

0  Emulation  ATE  (EATE)  providaa  aama  Input/output  functional  capability 
as  tha  old,  or  original  ATE  baing  raplaoad  by  EATE 

0  TPS  transportability  only  as  good  as  hardwara/softwara  salaction  and 
"tuning"  will  allow 

0  Hardwara  raoonfiguration  concapt  raquiras  raouriing  solution  to  ATE 
raplacamant  problam  on  an  appiloation>by*applioation  basis 
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VIASOmMARC 

•  QCNEMO  EMULATION  APPROACH  CAN  BE  UTILIZED  OVER 
A  SPCOTTSM  OF  A#PUCAT10NS 

noURIS.  ABE  EMULMION  PE  Aff  ROACH  —  SOrrSARi  HSOONnaUSAHON 

3.5  Critarla 

Ciitarla  to  salact  potantlal  solutions  to  rssolva  vartical  tast  problems  must 
ba  formulatad.  At  tha  prasant  tima,  primarily  thraa  potantlal  solutions  ara  availabla  to 
rasolva  vartical  tast  problems.  As  other  solutions  are  Identified,  criteria  for  tha 
salaction  of  each  proposed  solution  must  ba  formulatad. 
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It  should  bs  noted  that  a  combination  of  these  diagnostic  methods  may  be 
used  to  effect  vertical  test  solutions.  For  example,  common  ATE  may  be  utilized  at 
the  Factory,  Depot,  and  Intermediate  Levels  of  maintenance  and  tolerance  cone 
budgeting  may  tM  utilized  to  derive  teat  tolerances  at  the  Organizational  or  Platform 
Levels  of  maintenance.  Criteria  for  the  selection  of  each  of  the  identified  diagnostic 
solutions  Is  provided  in  the  paragraphs  that  follow. 

3.5.1  Tolerance  Cone  Budgeting  (TCB) 

Tolerance  Cone  Budgeting  should  be  utilized  when  life  cycle  cost  studies 
and/or  program  constraints  dictate  the  use  of  exJstlng  test  vehicles  In  the  factory  and 
In  the  field.  In  this  severe  type  of  environment,  tolerance  cone  budgeting  Is  the  only 
vertical  test  method  (VTM)  altemattve  available  to  the  support  system  manager. 

3.5.2  Modular  Emulation  ATE 

Modular  Emulation  ATE  should  be  utilized  when; 

1.  Old.  outmoded  ATE  Is  to  be  replaced  In  the  field  and  sunk  cost 
Investment  in  test  software  is  to  be  preserved,  and 

2.  Existing  factory  ATE  Is  not  cost  effective  or  technically  feasible  to 
upgrade.  Employing  common  ATE  in  both  the  factory  and  the  field  Is 
not  a  feasible  aKematfve. 

it  should  be  noted  that  the  utilization  of  modular  emulation  ATE  Implies 
the  preservation  of  tolerance  cone  budgeting  and  associated  test  limits  employed 
within  existing  test  program  sets.  In  essence,  the  modular  emulation  ATE 
replacement  concept  goal  Is  to  "preserve,”  within  the  maintenance  hierarchy,  the 
tolerance  cone  budgeting  contribution  of  the  "replaced”  ATE. 

3.5.3  Common  ATE 

Common  ATE  Is  the  preferred  VTM  approach  and  should  be  utilized  as  a 
VTM  for  the  following  scenarios: 

1 ,  New  program  starts.  Situations  In  which  test  equipment  and  TPs  have 
yet  to  be  specified  In  an  RFP.  Promulgation  of  the  concept  of  common 
modular  ATE  in  both  factory  and  field  should  be  the  VTM  strategy 
employed  in  this  situation. 

2.  Situations  In  which  critical  UUT  performance  parameters  have  small, 
but  measurable,  day-to-day  drift  variation  (I.  e.,  ”nomlnal  value  drift"), 
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Intrinsic  within  thems«lv«s.  Us*  of  common  ATE  will  mlnimizo 
moasursment  uncartainty  in  these  particular  situations. 

3.  Situations  In  which  critical  UUT  performance  parameters  are  "pushing" 
the  state-of-the-art  instrumentation  (I.  e.,  TAR  <  3:1). 

In  these  types  of  situations,  tolerance  cone  budgeting  becomes 
Impractical.  These  situations  will  cause  failure  of  the  prime  systems  to  perform  to 
speolfloatlon,  even  when  all  critical  performance  parameters  test  "good." 

Use  of  common  ATE  will  minimize  measurement  uncertainty  In  these 
particular  situations  by  virtue  of  the  fact  that  the  same  critical  parameters  are 
measured  at  other  levels  of  maintenance  with  the  same  common  ATE  and  TPS. 

4.0  DE8IQN  PROCEDURES  AND  DOCUMENTATION 

Traceability  of  the  testing  functions  and  parameters  throughout  all  levels 
of  maintenance  Is  Important  to  both  the  Government  Program  Office  and  the 
contractor.  To  achieve  satisfactory  traceability  for  both  government  and  Industry 
use,  documentation  of  the  testing  functions  and  parameters,  togsther  with  the 
environment  In  which  these  are  measured,  is  required.  This  documentation  must 
take  two  forms.  The  first  type  deals  with  documenting  the  approach  utilized  by  the 
contractor  to  establish  testing  tolerances.  MIL-STD-2165  Is  the  governing  standard 
for  documenting  the  method  used.  Task  202.2.1  of  this  standard  establishes  the 
approach  used  to  achieve  vertical  testability.  This  should  be  accomplished  during 
Dem/Val.  Task  203.2.1  of  MIL-STD-2166  documents  the  procedures  utilized  to 
achieve  vertical  testability.  This  Is  accomplished  during  Full-Scale  Development. 

Documenting  the  results  of  the  vertical  testability  analyses  Is 
accomplished  by  Invoking  MIL-STD-1619  or  MIL-STD-1345,  Test  Requirements 
Documents.  Caution  must  be  used  In  Implementing  these  standards.  Historically, 
the  test  requirements  documentation  was  often  prepared  after-the-faot  and  served 
no  useful  purpose,  except  to  document  that  these  parameters,  tolerances,  etc.,  had 
been  established.  However,  this  is  not  the  main  purpose  of  these  standards. 
Rather,  the  documentation  required  must  be  utilized  to  define  the  testing 
requirements  at  all  levels  of  maintenance  (Organizational,  Intermediate,  and  Depot) 
and  for  all  types  of  testing  (BIT,  ATE,  etc.).  Thus  this  documentation  plays  a  key 
part  In  the  diagnostic  design  process,  which  Includes  vertical  testability  analyses. 
When  requiring  Data  Item  Deliverables  under  MIL-STD-2ie6,  MIL-STD-1345,  and 
MIL-STD-1419,  the  CDRL  must  reflect  this  heed.  The  timing  of  generating  these 
test  requirements  Is  not  only  essential  In  the  design  of  the  testing  function,  but  must 
be  a  major  Input  In  the  development  of  the  technical  Information  which  supports  the 
testing  function  (e.  g.  technical  publications).  Thus  the  preparation  of  a  technical 
publication  or  software.  In  the  case  of  electronic  delivery  of  this  technical 
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in  th*  OMt  of  •l•otronlo  dollvtry  of  this  toehnical  Information,  must  dapand  on  tha 
timaly  praparatlon  of  tha  Tachnical  Raquiramants  Documant 

FIgura  7  dapicta  vartloal  tastabilHy  dasign  prooadurat  and  tha  assoolatad 
dooumantatlon.  Tha  vartical  tastabillty  aottvltlas  ara  tiad  to  tha  diagnostic  activltias 
found  In  tha  tha  Diagnostic  Activity  Roadmap  contained  naar  tha  beginning  of  this 
guide.  Dooumantatlon  of  both  tha  approach  to  vartloal  testability  analysis  and  tha 
performance  of  this  analysis  ara  documented  In  tha  Testability  Analysis  Report  (DI>T« 
7199),  which  Is  an  overall  testability  report  required  during  Dam/Val  and  PSD.  Cara 
must  be  taken  by  both  tha  Qovammant  Program  Office  and  tha  contractor  to  assure 
that  vartloal  testability  is  addressed  In  these  reports.  If  additional  Inatruotion  on  tha 
Data  Item  Dalivarablas  Is  required,  It  can  be  aocompllshad  through  tha  use  of  tha 
CDRL,  which  can  tailor  tha  DID. 

Tha  documentation  of  tha  vartloal  tastabillty  analysis  Is  contained  In  the 
Test  Raquiramants  Documents.  MIL*STD>1510  or  MIL*8TD*1345,  Test 
Rsqulramanta  Documents,  ara  tha  governing  standards.  Either  standard  can  be 
applied.  Tha  tasting  parameters  and  tha  teat  environment  Information  Inputs  to  tha 
test  programs  which  ara  generated  for  BIT,  ATE,  etc.,  and  tha  test  procedures  can 
be  utilized  as  a  direct  input  In  tha  preparation  of  technical  publications  or  other 
electronic  delivery  methods. 


I  TESTABILfTY/DIAGNOSTlC  DESIGN  TECHNIQUES 


APPENDIX  E 


Table  of  Contenta 


1.0 

OVERVIEW 

3 

2.0 

DESIGN  LEVELS 

4 

3.0 

GENERAL  CONSIDERATIONS 

5 

3.1 

On>Line/Off-Une  Testing 

5 

3.2 

Digital  Guidelines 

6 

3.3 

Analog  Guidelines 

9 

3.4 

LSI/VLSI/MIcroprDcessor  Guidelines 

10 

3.5 

Test  and  Maintenance  (TM)  Bus 

11 

3.6 

Applicability  To  Design  Levels 

12 

4.0 

STANDARD  TESTABILITY  APPROACHES 

12 

4.1 

Scan  Techniques 

12 

4.1.1 

Scan  Path 

12 

4.1.2 

Level-Sensitive  Scan  Design  (LSSD) 

18 

4.1.3 

Scan-Set 

19 

4,1.4 

Random  Access  Scan 

21 

4.1.5 

Scan  and  the  TM  Bus 

25 

4.1.6 

Boundary  Scan 

25 

4.1.7 

Applicability  to  Design  Levels 

25 

4.2 

Signature  Analysis 

26 

4.2.1 

Stimulus  Generation 

27 

4.2.2 

Signature  Development 

32 

4.2.3 

Signature  Analysis  and  the  TM  Bus 

35^ 

4.2.4 

Applicability  to  Design  Levels 

37 

4.3 

Wraparound  Techniques 

38 

4.3.1 

General 

38 

4.3.2 

Core,  ROM,  RAM  Testing 

38 

4.3,3 

Processor  Ccntrolied  Gating 

40 

4.3.4 

Apfiriicability  to  Design  Levels 

41 

4.4 

Analog  Te(^niques 

41 

4.4.1 

General 

41 

4.4.2 

Active  Versus  Passive 

42 

4.4.3 

Conversion  to  Digital  Format 

42 

4.4.4 

Applicability  to  Design  Levels 

43 

4.5 

Concurrent  Techniques 

43 

4,5.1 

General 

43 

E-1 


TESTABILfTY/DIAGNOSmC  DESIGN  TECHNIQUES  APPENDIX  E 


4.5.2 

Fault-Tolerarrt  Design 

46 

4.5.2. 1 

General 

46 

4.5.2.2 

Use  of  the  TM  Bus  with  Fault-Tolerant  Circuits 

50 

4.5.3 

Appiicabllfty  to  Design  Levels 

50 

5.0 

FAULT-ISOLATION  TECHNIQUES 

51 

5.1 

Test  Points 

52 

5.2 

Test  Header 

66 

5.3 

Increasing  I/O  Visibility 

67 

5.4 

Fault  Signature/Fautt  Dictionary 

59 

5.5 

Guided  Probe/Ciip 

69 

5.6 

Use  of  TM  Bus 

74 

6.0 

PHYSICAL  PACKAGING 

74 

6.1 

Surface  Mounted  Devices 

74 

6.2 

Chip  Carriers 

75 

6.3 

Small  Outline  (SO)  Packages 

77 

6.4 

Pin  Grid  Arrays 

77 

6.5 

Packageiess  Configurations 

80 

6.6 

Testing  Surface  Mounted  Devices 

80 

7.0 

TEST  AND  MAINTENANCE  BUS 

81 

7.1 

Overview 

81 

7.2 

VHSICTMBUS 

81 

7.2.1 

Physical  Requkements 

82 

7.2.2 

Electricai  RequiremerTts 

83 

7.2.3 

Data  Link  Recrements 

83 

7.2.4 

Element  TM  Bus 

84 

7.3 

Other  Initiatives 

84 

TESTABILmr/DIAONOSTIC  DESIGN  TECHNIQUES 


APPENDIX  E 


TB8TAMLrrY/DIAQN08T1C  DE8IQN  TECHNIQUES 
1.0  OVBRVIBW 

Weapon  ayatema  are  becoming  Inoreaalngly  complex  and  difficult  to 
aupport.  To  a  large  extent,  their  capability  to  be  available  to  auooeaafully  complete  a 
mlaalon  la  dependent  on  the  teatabillty  end  dlagnoado  ohareoterlatloa  dealgnad  Into 
their  aaaoolated  aupport  ayatema.  Theae  aupport  ayatema  oonalat  of  both 
embedded  (l.e..  on-line  BIT)  and  off-line  (I.e.,  external  teat  equipment/ATE)  teat 
oapebllKlea. 

.  Innovative  new  approachea  in  teat  lyatem  arohiteoture,  auoh  aa  the  virtual 
Inatrument  concept  and  expanded  pin  electronloa  techniquea  combining  analog  and 
digital  teat  capability  on  each  pin,  are  coming  together  to  enhance  ayatam 
readineaa.  Theae  advanoea  will  yield  the  higheat  probablitty  of  mlaalon  auooeaa  only 
when  a  dealgn  for  teatabillty  phlloaophy  la  Incorporated  in  the  earileat  atagea  of 
ayatam  acquIaHlon. 

Life  cycle  coat  trade-offa  between  the  varied  ayatem  elementa 
automatically  preclude  the  eatabilahment  of  a  aet  of  mandatory  teatabillty  featuraa 
for  all  procurement  evaluationa.  The  techniquea  and  applloatlona  Identified  herein 
provide  a  oomprehenalve  outline  of  thoae  prooeaaea  that  are  real,  available,  and 
acceptable  In  accordance  with  eatabllahed  apeolfleatlona  and  ayatem  goala.  They 
provide  a  baae  from  which  greater  ayatema  operational  availability  will  evolve  aa 
technology  alao  evolvea. 

The  aeotlona  to  follow  will  give  detailed  Information  on  teatabillty  and 
diagnoatio  dealgn  techniquea.  Section  2  la  devoted  to  the  vartoua  levela  of  dealgn 
according  to  the  hierarchy  of  Integrated  DIagnoatloa.  The  maintenance  apeotrum 
muat  deal  with  teating  at  the  ayatem  level,  teating  of  black  boxea  or  aubayatema  that 
are  parta  of  that  ayatem,  and  teating  of  boarda  or  modulea  which  are  part  of  the 
aubayatem  or  black  box.  The  oomponenta  on  thoae  boarda  muat  then  alao  be  dealt 
wKh  aa  part  of  the  overall  teating  apeotrum. 

Section  3  deala  with  general  conalderatlona  for  the  dealgner,  Included  la 
on-line  and  off-line  teating,  digital  guldellnea,  analog  guldellnea,  guldellnaa  for  LSI 
and  VLSI,  guldellnea  for  mlcroprooeaaora,  and  a  aectlon  on  the  use  of  a  teat  and 
maintenance  (TM)  bua. 

Section  4  deala  with  standard  testability  approaches  Including  scan 
techniquea.  Covered  In  this  general  category  of  scan  techniques  are  scan  path, 
level-senaltive  scan  dealgn,  acan  set,  random-access  scan,  and  scan  as  It  applies  to 
the  tost  and  maintenance  bus.  Alao  Included  Is  the  new  technique  of  boundary 
scan.  In  addition,  signature  analysis  Is  covered  In  detail.  Included  are  stimulus 
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9*n«ratlon,  th«  d«v»lopm«nt  o(  ilgnaturvt,  tlgnatur*  antlytlt  tnd  Ht  applicability  to 
tha  TM  bus,  and  tha  vartout  daslgn  lavala  In  which  slgnatura  analysis  can  ba  usad. 
Also  oovtrad  Is  tha  standard  mioroprooassor  wrap-around  taohniqua  including  tha 
dafining  of  oora  oparabHIty,  tha  tasting  of  Paad  Only  Mamorlaa  (ROM),  tha  tasting  of 
Random-Aooass  Mamortas  (RAM),  prooassor  oontrollad  gating,  tha  ganaration  and 
tha  oaptura  of  tha  tast  vaotora,  and  tha  applioabllHy  to  various  dasign  lavala.  Also 
disoussad  ara  various  analog  tachntquas  Including  aotiva  varsus  passive  tasting, 
analog  stimulus  ganaration  and  maasuramant,  eonvarsion  of  analog  signals  to  tha 
digital  format,  and,  finally,  appiloablilty  to  various  dasign  lavals.  Concurrent  tast 
taohniquas  ara  oovarad  In  Section  4,  including  conourrant  versus  non-raal  time,  tha 
new  pin  alaotronlos  arohHaotura,  fault-tolarant  design,  and  tha  appHoablllty  to  various 
dasign  lavals. 

Section  6  deals  with  fault  Isolation  taohniquas  Including  tha  use  of  tast 
points,  tha  use  of  a  tast  header  to  Increase  I/O  visibility,  fault  signatura/fault 
dictionary  as  a  fault  Isolation  technique,  and  tha  use  of  a  guided  probe  or  clip  for 
fault  Isolation.  Also  oovarad  Is  tha  use  of  tha  TM  bus. 

Section  6  Is  devoted  to  physical  packaging  Including  surface  mount 
davloas,  chip  carriers,  small  outline  packages,  pin  grid  arrays,  paokagalass 
configurations,  and  ths  tasting  of  surface  mount  davloas. 

Section  7  oovars  tha  use  of  a  tast  and  maintenance  bus.  Indudad  ara  tha 
VH8IC  TM  Bus,  tha  alamant  tast  and  maasuramant  bus,  plus  currant  efforts  on  tha 
part  of  tha  «rrAQ  Committaa  and  tha  IEEE. 

2.0  DESIGN  LEVELS 

Integrated  dlagnoatios  Is  an  alt*anoompasslng  disolpllna  that  Is  meant  to 
deal  with  dlagnoatios  at  all  levels  In  a  system.  For  many  yaara  tha  maintananoa 
spectrum  In  an  ideal  situation  operated  aa  followa:  tha  prime  system  (a.g.  an 
aircraft),  would  have  sufficient  bulH-ln  tast  In  order  to  ascertain  whether  or  not  tha 
system  was  working  correctly  or,  H  It  was  not  working  correctly,  to  ba  able  to  fault 
Isolate  to  a  malfunctioning  black  box  onboard.  Tha  suspect  black  box  would  ba 
removed  from  that  operational  scenario  and  returned  to  an  Intarmadlata-laval  shop 
for  tasting.  A  tast  system  In  tha  l-laval  shop  would  check  tha  suspect  black  box  to 
ascertain  whether  It  was  operating  oorraotly  or  If  It  did  Indeed  have  faults.  If  a  fault 
or  faults  ware  uncovered,  tha  procedure  would  ba  to  Isolate  to  one  or  more 
malfunotloning  printed  circuit  boards  or  modules.  Tha  faulty  board(s)  or  modula(s) 
would  ba  replaced,  tha  black  box  retested  and,  If  oparatbnal,  returned  to  tha  spares 
Inventory.  The  faulty  boards  or  modules  would  ba  returned  to  a  depot  for  testing  on 
a  different  plaoa  of  tast  equipment  which  would  ba  used  to  determine  whether  or  not 
they  ware  operational  or  whether  they  ware  malfunotloning.  If  they  ware  faulty,  tha 
approach  would  ba  to  Isolate  to  a  malfunotloning  component  or  components.  After 
replacement  of  these  faulty  oomponent(s),  tha  now  operational  board  would  be 
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returned  to  this  tptrtt  invontory.  This  ovtrsll  spprosch  rsquirsd  at  Isast  thrss 
lavs  Is  of  malntsninot. 

An  attsmpt  Is  now  undsrway  to  crsats  a  two-lsvsl  maintsnanca  losnario. 

This  ntwsr  approach  Is  an  attsmpt  to  sllminats  ths  1*10701  shop.  Tho  bulit*ln  tost  on 
board  tho  oporational  syatom  Is  Intondod  to  fault  isolato  without  ambiguity  to  a 
malfunctioning  lino  roplaeoablo  modulo.  That  suspoct  modulo  would  thon  bo 
rotumod  to  tho  dopot  for  ropalr.  This  proooduro  would  ollminato  tho  l-lovol  shop. 

Rogardloss  of  tho  maintonanoo  soonarlo,  whan  diagnostics  aro  built  Into  a 
syatom  thoy  can  bo  built  in  at  tho  chip  lovoi,  tho  board  or  modulo  lovol,  tho  black 
box  or  subsystom  lovol  and  tho  syatom  tovol.  SIneo  Intogratod  diagnostics  is  an  all 
onoompassing  disolpllno.  ovary  attompt  will  bo  mods  In  tho  following  oootlons  to 
point  out  at  what  tovol  or  lovols  tho  various  toohniquos  or  approaohos  aro 
applloablo.  For  oxampio,  whan  scan  toohniquos  aro  disoussod  in  Sootlon  4.1 ,  ovary 
offort  will  bo  mods  to  roeommond  at  what  lovol  of  tho  dosign  proooas  scan 
toohniquos  can  bo  utllliod  offoottvoly. 

0 

3.0  QINIRAL  C0N8IDIIUH0N8 

3.1  On-Uno/OfM.lno  Tooting 

Tho  dovolopmont  of  an  offootivo  syatom  support  stratogy  that  oapitalizos 
on  tho  currant  tronds  In  onhanood  altornato  mission  Idontifioatlon  capability  and 
fault'tolorant  dosign  Is  dopondont  on  unambiguous  orror  dotootlon.  Currant 
woapons  systom  oporational  softwaro  can  bo  rollod  upon  In  most  oasos  to  fault 
Isolato  tho  systom  to  a  dofootivo  black  box.  in  a  property  dosignod  systom,  utilizing 
a  TM  bus  and  supporting  BIT/BITE  circuitry,  maintonanoo  diagnostic  softwaro  will  bo 
ablo  to  fault  Isolato  to  a  dofootivo  card  or  modulo.  Tho  poroontago  of  fuutt  oovorago 
Is  a  function  of  tho  design  for  tostability  Investment  In  cost,  circuit  real  estate, 
program  roquiramonts  and  technology  capture. 

Tho  Increasing  population  density  of  VLSI  devices  Is  skewing  circuit  BIT 
dosign  momentum  toward  a  distributed  BIT  arohitooturo  whore  critical  circuit 
monitoring  oompononts  aro  Included  on  each  card.  This  can  bo  particularly  valuable 
when  a  dodloatod  maintonanoo  diagnostic  bus  allows  active  Injection  of  stimuli, 
derived  from  tho  BIT  Itself,  to  alter  tho  circuit  stats.  Active  BIT  oharactoiistlcs  can 
also  enhance  tho  capability  of  defining  systom  oporational  capacity  and  Identifying 
degraded  mode  mission  portormanco. 

Many  of  tho  dosign  for  tostability  onhaneomonts  that  are  required  to  yield 
a  significant  off-line  tost  capability  also  affect  on-line  testability.  Off-line  electronic 
modulo  and  board  sorooning  and  dofootivo  component  Identification  will  normally  bo 
aooompilshod  through  tho  use  of  ATE.  For  tho  purposes  of  this  discussion  It  Is 
assumed  that  tho  regiment  will  bo  Implomontod  In  hardware,  softwaro  and  firmware. 
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Th«  Allocation  of  tttt  function  rotponalblllty  botwotn  thoso  throo  •lomonta  Is 
dlctatad  by  the  syatam  design  goals  and  technology  level.  Following  segments  will 
address  the  off-line  testtng  of  boards  with: 

0  BIT/BITE 

0  Embedded  Scan  Design  or  Signature  Analysis 

0  Faun-Tolerant  Design 

0  Some  portion  of  Analog  Circuitry. 

The  archHeoture  of  the  supporting  ATE  has,  In  the  past,  been  determined 
to  a  large  extent  by  the  system  to  be  tested.  Now  the  designer  of  a  oiroult  who  Is 
aware  of  the  newest  and  moat  powerful  test  teohniques  can  alter  the  testability 
profile  signifloantly  at  an  early  stage  In  the  acquisition  process.  For  this  reason,  the 
use  of  regular  Input/output  pins  and  Inoorporatlon  of  a  test  header  becomes  an 
Inexpensive  adjunct  to  facilitating' testability  when  the  ATE  has  the  capability  of 
controlling  the  state  of  each  pin.  This  enhanced  taster  capability  supports  the  off¬ 
line  testing  philosophy. 

Other  considerations  In  maximizing  fault  Isolation  eftlolenoy  during  the  off¬ 
line  testing  of  oiroult  boards  are  greatly  Impacted  by  the  physical  layout  of  the  board. 
The  effeota  of  pin  positioning  and  surface  mount  device  conformation  forces 
alternate  probing  teohniques.  In  many  oases,  unless  test  aooesaibility  Is  designed 
Into  the  board  (test  headerAest  points),  the  board  may  not  be  eoonomloally  tested  at 
the  Intermediate  level  and  will  be  coded  for  depot  repair  or  scrap.  The  ability  of  the 
circuit  card  designer  to  capitalize  on  the  advantage  of  the  newer  packaging 
teohniques  will  be  enhanced  If  consideration  Is  given  to  including  a  bullt-ln  access 
route  to  the  orltioal  nodal  points. 

3.2  Digital  OuMellnee 

All  oiroult  design  must  support  the  overall  maintenance  concept.  It  Is  of 
particular  Importance  that  the  maintenance  concept  and  its  Implementation 
approach  be  finalized  before  any  design  efforts  begin.  Table  1 ,  Diagnostic  Support 
Activities,  provides  a  listing  of  the  seven  specific  actions  that  need  to  be 
accomplished  to  provide  adequate  condition  monitoring  and  svaluatlon  of  a  circuit’s 
performance  capability.  The  acquisition  program  goals  of  operational  availability 
and  Ilfs  cycle  cost  will  determine  the  actual  depth  of  application  of  each  of  these 
activities.  For  example,  off-line  fault  isolation  capability  will  be  determined  by  the 
size  of  the  ambiguity  group  for  failed  components,  the  ATE  characteristics  required, 
the  extent  of  manual  intervention  and  the  system  software  characteristics. 
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TABLE  1  DIAGNOSTIC  SUPPORT  ACTIVITIES 

Activity 

Result 

Performance  Monitoring 

Continuous  system  status 

Confidence  self  teat 

Test  on  demand,  report  status 

Diagnostic  self  teat 

Test  on  demand.  Identify  failed  item 

OO'IInt  sorMning  t«at  Acoapts  aignal  manipulation  to  datermlna 

ayitam  atatua 


On*lina  Ulagnoatlo  taat  Aooapta  aignal  manipulation  to  datarmlna 

faulty  module 


Off'ltne  screening  test 

Test  saquenoe  that  Identifies  maximum 
number  of  failures 

Off-line  fault  Isolation 

Test  saquenoe  that  identifies  component 
failure 

The  dealgn  teohnlquei  to  be  uaed  that  will  provide  tha  daairad  level  of 
teatablllty  are  teohniquea  that  aupport  one  or  more  of  the  following  strateglaa: 

o  Making  circulta  Initlallzable 
o  Providing  meaaurement  teat  points 
o  Providing  atimuiua  teat  polnta 
0  Partitioning  the  circuit  for  teatablllty 
o  Providing  teat  data  collection  and  distribution  circuitry 
0  Embedding  aelf*test  in  the  circuit  using  microprooessora 
o  Monitoring  perfonnance  of  the  circuit. 

Specific  circuit  arrangement  Is  required  to  accompliah  each  of  the  Items 
cited  above.  For  Instance,  In  order  to  evaluate  a  circuit's  condition,  It  must  be  In  a 
speoHIo  state  (usually  initialized).  For  example,  In  the  ease  of  a  memory  circuit,  an 
Input  Identified  as  clear  (CLR)  Is  brought  to  some  edge  connector  and,  on  demand, 
a  pre>determlned  pin  state  Is  established. 

The  following  Items  provide  a  comprehensive  list  of  general  digital  module 
testability  guidelines; 

o  Circuitry  shall  be  Initlallzable  to  a  welUdefIned  state  to  commence 
test/pattem  development. 
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0  All  mtmory  alamants  must  ba  abla  to  ba  switchad  to  both  logic  statas 
(l.a.,  logic  ”0/1")  and  tha  output  statas  for  a  givan  sat  of  spaciflad 
conditions  must  ba  pradictabla.  In  soma  oasas,  diraot  data  Input  (l.a.. 
pra*sat  Input)  to  tha  mamory  circuit  must  ba  providad  to  affaot  afflolant 
loading  of  mamory  alamants  with  Initialization  of  fast  data. 

0  Tast  oovaraga  loss  In  a  countar  Is  diractly  proportional  to  tha  dagraa  of 
tha  constraints  that  ara  Imposad.  Tastablllty  can  ba  at  least  partially 
rsstorad  In  these  oases  by  Insuring  that  tha  hIgh-order  bit  of  tha 
counter  ba  an  observable  output. 

0  A  mode  control  should  not  ba  removed  from  tha  counter  or  shift 
ragistsr. 

0  Tha  Load  or  Clock  Unas  of  a  counter  should  not  ba  driven  from  tha 
mamory  outputs  of  tha  same  counter. 

0  All  ROM  and  RAM  outputs  must  ba  observable  at  tha  module  I/O 
connector.  Tha  Chip  Select  line  of  all  ROMS  and  RAMS  must  not  ba 
fixed  at  tha  logic  polarity  which  allows  active  operation.  RAMS  shall 
allow  sufficient  control  by  tha  taster  to  perform  standard  memory  tests 
such  as  galloping  patterns. 

0  A  Single  Shot  can  ba  used  to  drive  tha  Clock  line  of  a  mamory  block 
without  loss  of  tastablllty.  If  tha  Single  Shot  drives  combinational 
circuitry,  there  can  be  significant  loss  of  tastablllty. 

0  Long  strings  of  sequential  logic  should  ba  broken  and  raconnaotad  via 
gate  control. 

o  Large  feedback  loops  should  ba  broken  and  raconnaotad  via  gate 
control. 

0  Multiple  reset  Unas  should  ba  provided  Instead  of  one  common  reset 
line  for  a  large  number  of  memory  blocks. 

0  All  parity  checkers  and  generators  must  be  switchabla  to  both  output 
logic  statas. 

o  All  analog  signals  and  grounds  must  be  separated  from  the  digital 
logic. 
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0  Any  dtvioe  that  doaa  not  have  a  pradictable  output  must  be  separated 
from  all  digital  lines. 

0  WIred'OR  signals  that  originate  from  five  or  more  different  physical 
locations  must  be  separated  Into  smaller  groups. 

0  The  number  of  module  designs  and  1C  types  should  be  minimized. 

0  The  module  characteristics  (function,  pin  count,  clock  rate,  etc.)  shall 
be  compatible  with  planned  ATE  resources. 

0  Error  correction  functions  must  have  the  ability  to  be  disabled  so  that 
the  primary  circuit  can  be  tested  Independently  for  faults. 

3.3  Analog  Quidellnea 

Analog  modulo  testability  guidelines  include  the  following  Items: 

0  Input  and  output  pins  should  be  physically  separated. 

0  All  outputs  exceeding  one  amp  should  have  multiple  output  pins  if 
voltage  level  Is  critical.  This  allows  a  Kelvln*type  connection  of  the 
analog  outputs  and  enables  voltage  sensing  and  feedback  to  the 
current  control  circuitry  in  the  UUT.  Consequently.  Kelvin  connection 
capability  permits  a  prescribed  voltage  to  be  maintained  at  the  UUT 
output  tenninals. 

0  Intermediate  stages  of  a  circuit  should  be  independently  testable  by 
breaking  signals  through  the  I/O  connector. 

o  The  output  of  all  stages  of  an  analog  circuit  should  be  available, 
through  Isolation  resistors,  to  a  module  pin. 

0  Modules  with  complex  feedback  circuits  should  have  the  capability  to 
disconnect  the  feedback  to  allow  Independent  test  of  the  feedback 
and/or  devices. 

o  All  Internally  generated  reference  voltage  levels  should  be  brought  out 
to  module  pins. 


o  All  digital  control  functions  should  be  Independently  testable. 
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3.4  L8l/VL8l/Microproc«Mor  QulCtoilMt 

Digital  LSI/VLSI/mlcroproc086or  module  testability  improvement  is 
accomplished  by  applying  the  concepts  listed  below; 

0  Direct  parallel  access  to  LSI/VLSI/microprocessor  devices  shall  be 
provided  to  the  maximum  extent  possible.  Support  circuits  driving  the 
inputs  of  the  LSI/VLSI/mioroprocessor  should  be  tri-statable,  allowing 
the  tester  to  drive  the  Inputs  directly. 

0  .'revisions  shall  be  made  for  allowing  tester  control  of  trI-state  enable 
lines  and  the  outputs  of  tri-state  devices. 

0  If  bidirectional  bus  drivers  are  used  In  a  microprocessor  module 
design,  they  shall  be  located  between  the  proeessor/oontroller  and  any 
of  Its  support  chips.  The  controls  for  bidirectional  buffers  on 
microprocessor  I/O  pins  should  be  easily  controllable,  and  preferably 
automatically  controlled  by  the  microprocessor  without  the  tedious  task 
of  deciphering  whether  the  microprocessor  pins  are  inputs  or  outputs 
for  each  pattern  applied. 

0  Signal  breaks  should  be  used  to  provide  access  to  various  data  buses 
and  control  lines.  If,  due  to  I/O  pin  limitations,  this  cannot  be  done 
then  scan  In/soan  out  and  multiplexing  circuity  should  be  consldored. 

0  Select  components  with  known  properties  (internal  structure,  device 
function,  failure  modes,  controllabllity/observablllty,  etc.)  and 
preferably  with  functional  patterns  already  In  existence  (MIL-M-38510 
or  other  high-quality  test  patterns). 

0  Make  buses  available  to  the  tester.  The  data  bus  is  the  highest 
priority.  Tester  control  of  a  bus  Is  the  most  desk  able  feature,  although 
monitoring  capability  alone  will  help  fault  resolution. 

0  A  microprocessor  on  a  module  with  other  complex  logic  devices 
should  not  be  Ignored  as  a  test  resource.  Once  recognized,  it  is 
essential  that  the  necessary  features  be  incorporated  in  the  design  to 
use  this  resource. 

0  Provide  ATE  control  of  clocks  through  Inhibit/over-rlde  techniques  or 
by  direct  Independent  pinout. 

0  Provide  for  "single-stepping"  of  dynamic  mlcroprocessors/devlces,  If 
possible. 
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o  Partitioning  can  be  anhanoad  by  the  uaa  of  tri-atata  buses,  thereby 
reducing  module  testing  to  a  series  of  device  functional  block  tests. 

o  TrI-state  devices  should  utilize  pull-up  resistors  to  control  the  float 
level.  This  helps  simulators  avoid  the  Introduction  of  unknown  states 
Into  the  circuit  during  automatic  test  vector  generation. 

0  Free-running  clocks  and  power-up-reset  functions  should  not  be 
directly  connected  to  the  LSI/VLSI/microprooeasor  in  a  manner  such 
that  they  cannot  be  disabled  and  tested  Independently. 

o  Controllability  and  observability  of  all  BITE  designed  Into  LSI, 
VLSI/hybrid,  or  microprocessor  devices  shall  oe  provided  to  the 
module  I/O  connector. 

3.8  Teat  and  Maintenanee  O'M)  Bus 

The  use  of  a  standard  bus  for  testability  provides  a  most  significant 
opportunity  to  enhance  the  effectiveness  of  module  and  system  testing.  The 
Incorporation  of  a  TM  bus  need  not  be  overly  restrictive  on  Its  users  since  it  need  not 
dictate  the  form  of  testability  Implementation  on  the  unit  under  test  (UUT)  or  the 
actual  codes  that  transverse  the  bus.  More  importantly.  It  gives  the  government  the 
mechanism  to  require  each  user  to  build  testability  Into  his  designs  and  gives  the 
means  to  negotiate  specHIc  testability  requirements  with  each  equipment  supplier. 

The  functions  which  a  standard  TM  bus  should  Implement  Include  the 

following: 

o  Input  pattern  Information  to  UUT 
o  O^ut  pattern  Information  from  UUT 
o  Clock  Signal 
0  Addressing 
o  Enable/disable  control 
o  Interrupt 
o  React. 

Implementation  of  these  functions  In  a  parallel  fashion  maximizes  the  data 
transfer  rate  but  requires  an  Increased  number  of  input/output  pins.  A  serial 
approach  reduces  the  Input/output  pin  requirement  but  functions  at  a  slower  speed. 
The  recommended  approach  uses  a  serial  path  for  test  and  maintenance  control 
and  data  Information.  Action  7.0  describes  this  subject  In  more  detail. 
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3.6  ApplioabIHty  To  Dotign  Lovols 

Tho  objootlvo  of  Sootlon  3  Is  to  Identify  ostabllshed  tostablllty/dlagnostlo 
toohnlquat  that  should  ba  considarad  for  Incorftoratlon  in  tha  design  of  alaotronlo 
cards/teards/modulas  Idantiflad  for  use  in  modem  weapon  systems.  The  ultimate 
goal  Is  to  ensure  that  the  teatabllHy  features  contribute  significantly  to  an  Improved 
operational  availability.  Although  general  In  nature,  their  applioabillty  Is  more 
germane  to  board/module  level  considerations. 

4.0  STANDARD  TESTABILITY  APPROACHES 

4.1  Scan  Teehniquea 

Aa  digital  circuits  have  become  more  oompllcated.so  the  test  patterns  for 
comprehensive  fault  coverage  have  become  more  complicated  and  longer.  This 
trend  continued  to  the  point  that  It  often  became  Impractical  for  a  test  engineer  to 
develop  a  comprehensive  pattern  set  manually.  Automatic  test  program  generators 
and  simulators  were  developed  to  help  the  test  engineer.  The  size  of  digital  circuits 
has  continued  to  grow,  however,  to  the  point  that  generating  test  patterns  and 
simulating  fault  coverage  on  the  most  powerful  automatic  test  program  generators 
can  be  very  expensive  and  time  consuming. 

Scan  techniques  are  a  group  of  design  methodologies  that  separate 
combinational  logic  and  sequential  logic  into  separate,  easily  testable  groupings. 
Scan  design  depends  upon  the  fact  that  digital  logic  may  be  partitioned  into  groups 
of  combinational  logic  separated  by  sequential  logic.  (See  Rgure  1 .) 

4.1.1  Scan  Path 

In  the  soan<path  technique  the  circuit  Is  designed  so  that  H  has  two  modes 
of  operation:  one  that  Is  the  normal  functionai  mode  and  another  that  Is  a  test  mode 
in  which  the  circuit  flip-flops  are  Interconnected  Into  a  shift  register.  With  the  circuit 
In  test  mode,  it  is  possible  to  shift  an  arbitrary  test  pattern  Into  the  flip-flops,  By 
returning  the  circuit  to  normal  mode  for  one  clock  period,  the  combinational  circuitry 
can  act  upon  the  (llp-flop  contents  and  primary  input  signals  and  then  store  the 
results  In  the  flip-flops.  If  tho  circuit  Is  then  placed  Into  test  mode,  It  Is  possible  to 
shift  out  the  contents  of  the  flip-flops  and  compare  these  contents  with  the  correct 
response. 


In  the  following  discussion  of  scan-path  techniques,  It  Is  assumed  that  the 
circuit  is  constructed  of  flip-flops  Interconnected  by  combinational  networks.  It  will 
also  be  assumed  initially  that  all  of  the  flip-flops  are  clocked  by  a  single  common 
clock  signal.  These  assumptions  mean  that  the  circuit  can  be  considered  to  have 
the  general  structure  shown  in  Figure  2.  Drawing  the  circuit  In  this  form  Is  done  to 
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nouRE  1.  PARrnrnoNiNo  op  circuits  for  scan  design 


FIGURE  2.  GENERAL  STRUCTURE  OF  CIRCUITS  FOR  SCAN-PATH  DISCUSSION 
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simplify  th«  following  o,  but  Is  not  mssnt  to  Imply  any  rsitrlotlons  on  tha 
dssignsr,  othar  than  tN  abova. 

Tha  struotunrad  hara  Is  tha  moat  common  typa  of  digitti  circuit 
and  Is  tha  aaslast  to  nv  tha  scan-j^h  taohniqua.  D  fllp*flops  ara  shown  In 
FIgura  2  and  will  ba  usiollowing  dtocusslon.  Tha  sama  ganaral  rasuHs  hold 
trua  If  othar  typas  of  flips,  JK,  T,  ate.  -  ara  usad.  Baoausa  tha  axtanslon  to 
othar  fllp*ftops  Is  stralghths  datsils  will  not  ba  prsssntad  hart. 

It  Is  Importstlngulsh  batwaan  latohas  and  fllp'flops.  This 
distinction  Is  lllustratads  3.  A  latch  has  tha  transparsnoy  proparty;  If  tha 
data  Input  ohangss  whock  Is  aotiva,  tha  latch  output  will  follow  tha  data 
Input  ohanga.  This  Is  llln  FIgura  3  by  tha  ohangas  In  tha  Q  latch  wavafonris 
at  timas  21, 26,  and  3<flop  ohangas  only  whan  tha  clock  Input  makas  a 
apaolflo  transition  •  thaansitlon.  For  tha  fllp>flop  In  FIgura  3,  tha  aotiva 
transition  of  tha  clock  litre  whan  tha  clock  ohangas  from  zsro  to  ona.  Tha 
fllp’flop  output  takas  alus  prasant  at  tha  data  Ihput  whan  this  aotiva 
transition  occurs.  Subohsngas  of  tha  dais  Input  hava  no  affaot  until  tha 
naxt  aotiva  transition  of  I 

An  Impertantsristio  of  flip*flops  Is  that  a  shift  ragistar  oan  ba 
oonstruotad  by  oonnaotli^  of  ona  fllp<fiop  diraotly  to  tha  data  Input  of  tha 
naxt  flip-flop.  Tha  oonvia  latch  ragistar  to  a  shift  ragistar  rsquiras  an  axtra 
latch  batwaan  aaoh  ragit. 

In  ona  taohnlo  of  tha  circuit  ftip-flopa  Is  raplaoad  by  tho  flip-flop 
struotura  shown  In  FIgunultIplaxar  Is  pisiosd  at  ths  data  Input  to  parmit  a 
salaotlon  of  two  dlffararputs  *  dO,  or  normal  systam  operation;  and  d1,  or 
tast  moda.  Tha  oholoa  iput  Is  based  on  tha  value  of  tha  control  Input,  T. 
Whan  T  ^als  zero,  datd  from  tha  dO  Input  upon  an  aotiva  clock  trans  Hon. 
Data  Is  taken  from  d1  If  Trna.  A  typa  D  flip-flop  'vNh  muHIplaxad  data  Inputs, 
such  as  In  FIgura  4<a),  wM  a  multl^xad  data  flip-flop  or  MD  flip-flop. 

It  should  ba  nctha  design  of  Rgura  4  has  tha  undesirable  feature 
of  Increasing  tha  propagay  of  tha  flip-flop.  This  Is  not  Inherent  In  an  MD  flip- 
flop.  Tha  additional  daba  atimlnatad,  except  possibly  for  tha  affect  of 
addIHonal  gate  fan-ln,  byilng  tha  flip-flop  to  Incorporate  ths  multiplexer  Into 
tha  flip-flop  circuitry. 

Tha  modificatlobaslo  circuit  struotura  of  Figure  2  to  obtain  a  scan- 
path  archHaoture  using  S^s  Is  shown  In  Rgura  5.  Ona  additional  Input,  tha 
T  Input,  has  bean  addad.mal  operation,  T  Is  equal  to  zero  and  tha  circuit  is 
oonnaotad  as  In  FIgura  2>psr  data  Inputs  (Y^...Y.)  originate  from  Internal 
nodes  of  combinational  oiling  obsanrad  and  act  as  the  flip-flop  D  Inputs.  In 
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ord«r  to  tost  th«  oiroult,  It  ttt  tqutl  to  ont.  Tho  lowtr  data  Inputa  baooma  tha  flip- 
flop  0  Inputa.  Thus,  D|  tquala  Q|  ‘1  for  I  from  2  to  a,  and  a  ahift  raglatar  la  formad. 

Tha  primary  Input  la  oonnaotad  to  D1  and  baoomaa  tha  ahift  raglatar  Input.  Tha 
ahift  raglatar  output  Q,  appaara  at  tha  primary  output  Z^. 

Taating  of  tha  oomblnatlonal  logio  la  aooompllahad  by: 

0  Satting  T  aqual  to  ona.  or  aoan  moda; 

0  Shifting  tha  teat  pattam  yj  valuaa  Into  tha  flip-flopa; 

0  Satting  tha  oorraaponding  taat  valuaa  on  tha  X|  Inputa; 

0  Satting  T  aqual  to  zaro  and  aftar  a  aufflolant  tima  for  tha  oomblnatlonal 
logio  to  aattia,  ohaoking  tha  output  valuaa; 

0  Applying  a  clook  aignal  to  CK; 

0  Satting  T  aqual  to  ona  and  ahifting  out  tha  flip-flop  oontanta  via  Z^^. 
Tha  naxt  yi  taat  pattarn  oan  ba  ahiftad  In  at  tha  aama  tIma.  Tha  yj 
valuaa  ahlftw  out  ara  oomparad  with  tha  good  raaponaa  valuaa  for  yj.  ' 

Tha  flip-flop  muat  alao  ba  taatad.  Thia  la  aooompllahad  by  ahifting  a  atring 
of  onaa  and  than  a  atring  of  laroa  •  or  a  atring  of  altarnating  onaa  and  zaroa  - 
through  tha  ahift  raglatar  to  varify  tha  poaalblllty  of  ahifting  both  a  ona  and  a  zaro  Into 
aaoh  flip-flop. 

A  numbar  of  manufaoturara  hava  adoptad  DPT  mathoda  that  ara  vary 
almllar  to  thIa  aoan-path  aohama.  Tha  mitior  diffaranoaa  ara  In  tha  baalo  aoan-path 
blitabla  alamant  daaign  and  In  tha  way  in  which  tha  aoan  path  la  Intarfaoad  with  tha 
functional  oIrouKry. 

A  baalo  raquiramant  of  tha  aoan-path  taohniqua  la  that  It  la  poaalbla  to 
gata  data  Into  tha  ayatam  fllp-ftopa  from  two  dHfarant  aouroaa.  Ona  mathod  of  doing 
thia  la  to  add  multiplaxara  to  tha  ayatam  flip-flopa  aa  ahown  In  PIgura  5.  Another 
poaalblllty  la  to  raplaoa  aaoh  ayatam  flip-flop  with  a  two-port  flip-flop,  which  la  a  flip- 
flop  having  two  control  Inputa  and  Ita  data  aouroa  datarmlnad  by  which  control  la 
pulaad. 

A  oiroult  for  a  two-port  flip-flop  la  ahown  In  Figure  6.  Whan  a  pulaa  la 
applied  to  CK1,  data  la  antarad  from  D1;  and  whan  a  pulaa  occura  at  CK2,  data  la 
antarad  from  D2.  Tha  two-port  flip-flopa  ara  prafarrad  over  MD  flip-flopa  because 
uaing  them  make  It  aaalar  to  Implement  tha  control  for  a  atruotura. 
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nOURES.  1V/0-PORT  D  FUP-FIDP 

FIgura  7  thowt  tht  itruotur*  of  •  notwork  with  two<port  fllp>tlopt  uitd  to 
provido  tht  toan  path.  Tht  ttatlng  prootdurt  It  batloally  tht  aamt  aa  that 
dtaorlbtd  In  oonntotlon  with  Flgura  6.  In  tht  oirouK  of  FIgurt  7,  changing  batwaan 
tact  modt  and  normal  modt  la  aooompllahtd  by  changing  tht  clocking  rathar  than 
by  changing  tht  modt  tignal  (Syttam  Clock  it  8CK . . .  Taat  Clook  It  TCK). 

4.1  Ltvti-StntlUvt  8oan  Dttign  (L880) 

Soma  tyttami  art  dtaigntd  to  uat  latohaa,  rathar  than  fllp-flopt,  aa  tht 
blatabla  alamanta.  For  latoh*baaod  lyatama  It  la  not  pocalbit  to  rtoonfigurt  tht 
•yatam  blatabla  alamanta  diraotly  Into  a  ahlft  raglatar  for  taat  purpoaaa.  Savaral 
diffarant  approaohaa  hava  baan  davalopad  to  parmit  control  and  obaarvatlon  of  tha 
ayatam  latohaa  through  a  amall  numbar  of  I/O  pina. 

Ona  of  tha  moat  popular  taohniquaa  for  Introducing  aoan*path  taatablllty 
Into  latoh'baaad  ayatama  la  L8SD.  L8SO  la  a  acan-path  daaign  mathod  (or  latch- 
baaad  ayatama.  In  thia  mathod,  aach  ayatam  latch  la  raplacad  by  a  two-port  latch, 
and  LI  latch.  A  aacond  aingla-port  latch,  an  L2  latch,  la  addad  to  parmit 
reconfiguration  of  tha  ayatam'a  latohaa  Into  a  ahlft  raglatar  (or  taat  purpoaaa.  Tha  LI 
latch  la  a  two-port  latch  that  la  diraotly  analogoua  to  a  two-port  flip-flop.  It  la  a  latch 
with  two  data  Inputa,  aach  of  which  la  controllad  by  a  aaparata  clock.  ThIa  mathod  la 
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ROURE  7.  GENERAL  STRUCTURE  0^  CIRCUIT  USING  T^-PORT 
FUP-FLOPS  TO  PROVIDE  SCAN  PATH 


oalltd  lavfl-atniltlva  baoautt  tht  latehat  art  haxard  fraa:  that  la,  thay  art  not 
dapandant  on  tha  olook  riaa  and  fall  tlmaa  for  oorraot  oparatlon. 

A  ganaral  atruotura  for  a  ayatam  daaignad  uaing  tha  LSSD  taohniqua  la 
ahown  In  FIgura  8.  During  normal  oparatlon,  tha  ayatam  la  clookad  with  two 
Intarlaavad,  non*ovarlapplng  pulaa  tralna  appllad  to  tha  CK1  and  CK2  Inputa. 

4.1.3  8oan-8at 

'  All  of  tha  pravloua  mathoda  uaa  tha  functional  ayatam  fllp'flopa  or  latohaa  to 
aoan  taat  data  Into  and  out  of  tha  oiroult.  It  la  alao  poaalbla  to  add  to  tha  functional 
oiroultry  a  ahift  raglatar  whoaa  aola  purpoaa  la  tha  ahifting  In  and  out  of  taat  data.  Nota 
that  In  thia  taohniqua  tha  tarm  "fllp<flop”  maana  althar  a  latch  or  fllp*flop.  Whan  It  la 
naoaaaary  to  diatingulah,  a  latch  It  oallad  a  "latch  flip-flop”  and  a  flip-flop  la  oallad  an 
"adga-triggarad  flip-flop.”  Tha  raaulting  atruotura  la  ahown  In  Figure  B. 

Taat  data  la  ahiftad  Into  tha  flip-flop  raglatar  (FF1  -  FFa)  from  tha  SDI 
oonnaotlon  by  clocking  TCK.  Tha  taat  data  la  tranafarrad  In  parallel  to  tha  ayatam 
latohaa  through  thair  2D  Inputa  by  applying  a  pulaa  to  UCK.  Scanning  out  tha  latch 
data  la  tha  ravaraa  procaaa;  tha  latch  contanta  are  loaded  In  parallel  Into  tha  ihift 
raglatar  by  pulaing  DDK.  Shifting  out  other  raglatar  contanta  Is  aooomplishad  by 
clocking  TCK.  Tha  data  la  ahiftad  to  tha  Shift  Data  Out  (SDO)  terminal. 
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FIGURE  8.  GENERAL  STRUCTURE  OF  CIRCUIT  USING  TM/O-PORT 
LATCHES  TO  PROVIDE  SCAN  PATH-LSSO  DOUBLE-LATCH  DESIGN 


FIGURE  9.  GENERAL  STRUCTURE  OF  CIRCUIT  USING  SCAN-SET  TECHNIQUES 


E-20 


TESTABILfTY/DIAGNOSTlC  DESIGN  TECHNIQUES 


APPENDIX  £ 


To  Implement  the  structure  of  Figure  9,  the  system  latches  must  be  converted 
Into  two-port  latches  and  a  shift  register  stage  must  be  added  for  each  such  latch. 
There  Is  more  hardware  overhead  in  this  technique  than  in  LSSD;  two  latches  per 
system  latch  for  scan-set  versus  one  latch  per  system  latch  for  LSSD.  Both  techniques 
require  the  conversion  of  the  system  latohes  Into  two-port  latches.  Scan-set  requires 
one  shift  register  stage  per  system  latch  and  each  such  stage  requires  the  equivalent  of 
two  latches. 

Scan-set  does  have  on  important  advantage  compared  with  the  techniques 
described  above;  with  scan-set  it  Is  possible  to  gate  the  latch  contents  Into  the  test  shift 
register  during  normal  system  operation.  This  provides  a  means  for  getting  a  "snap¬ 
shot"  of  system  status.  Another  Important  feature  of  scan-set  is  the  ability  to  scan 
circuit  nodes  other  than  latch  outputs  into  the  test  shift  register,  Thus,  It  has  the  ability 
to  introduce  observation  test  points  at  non-iatch  nodes. 

All  of  the  previously  discussed  scan-path  teohnlques  use  a  shift  register  to 
convert  between  aerial  and  parallel  data.  Serialization  of  parallel  data  can  also  be  done 
with  a  multiplexer,  A  circuit  structure  with  a  multiplexer,  which  Is  used  to  scan  out  the 
system  latches,  Is  shown  In  Figure  10.  Use  of  more  than  one  scan-out  point  Increases 
the  speed  of  scanning  and  also  Increases  the  number  of  I/O  connections  required.  One 
possibility  for  avoiding  this  increase  Is  to  place  multiplexers  on  output  pins  to  permit 
some  of  the  output  pins  to  be  used  both  for  system  output  and  for  scanning  out  test 
data. 


With  a  multiplexer  scan  structure,  nodes  other  than  latch  outputs  can  be 
accessed.  The  scanning  operation  can  take  place  while  the  system  Is  operating. 
Complete  scan  out  of  all  scan  points  Is  simplest  If  the  scan  data  address  register 
can  be  configured  as  a  counter  that  steps  through  all  addresses  when  clocked. 

This  multiplexer  structure  Improves  the  observability  of  a  design,  but  does 
nothing  for  the  controllability.  Setting  of  the  system  latches  can  be  aocompllehed 
with  a  demultiplexer.  The  use  of  a  demultiplexer  for  setting  the  system  latches  and 
a  multiplexer  for  scan  out  forms  the  basis  for  the  random  access  structure. 

4.1.4  Random  Access  Scan 

The  principles  of  multiplexing  and  demultiplexing  can  be  used  to 
Implement  a  scan  technique  for  latch-based  systems.  A  simplified  version  of  the 
latch  design  used  is  shown  in  Figure  1 1 .  This  Is  called  an  addressable  latch.  Inputs 
1D(Y1)  and  C1(CK)  are  used  during  normal  system  operation. 
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FIGURE  10.  GENERAL  STRUCTURE  OF  CIRCUIT  USING  MULTIPLEXER  TO 
SCAN-OUT  lATCH  CONTENTS 
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In  ordttr  to  access  Latch  I  for  test  purposes,  the  signal  "select  I"  must  be 
set  to  one.  With  "Select  r  equals  one,  the  latch  content  is  placed  on  SDO  (I)  and 
SDI  is  clooKed  into  the  latch  If  TCK  Is  pulsed.  The  structure  of  a  system  using  these 
latches  Is  shown  In  Figure  12. 

There  Is  associated  with  the  circuit  an  address  register  whose  contents 
are  decoded  to  produce  the  "Select  I"  signals.  At  most,  one  of  these  signals  Is  equal 
to  one  at  a  given  time.  Data  are  scanned  into  the  latches  by  placing  the  latch  I  data 
value  on  SDI,  the  I  address  in  the  address  register,  and  then  pulsing  TCK.  The 
address  register  Is  Implemented  as  a  counter.  Thus,  a  sequence  of  data  can  be 
scanned  Into  the  latches  by  placing  the  sequence  on  SDI  and  pulsing  the  address 
register  counter  and  TCK  In  the  proper  time  relationship. 

The  latch  contents  are  scanned  out  vie  SDO  by  pulsing  the  address 
register  to  select  the  latches  In  turn.  An  Important  feature  of  this  structure  Is  the 
ability  to  scan  out  the  latches  during  normal  system  operation. 

Actual  Implementations  of  this  technique  using  addressable  latches  have 
two  or  three  select  signals  per  latch.  These  signals  are  decoded  at  each  latch  using 
the  circuit  shown  in  Figure  13  for  the  case  of  two  select  signals.  Somewhat  more 
complex  latches  are  used  In  the  actual  systems  In  order  to  take  advantage  of  the 
Emltter*Coupled  Logic  (ECL)  technology  and  minimise  the  penalties  due  to 
addressability. 

A  number  of  different  methods  tor  providing  circuitry  that  allow  access  to 
Internal  nodes  through  a  very  small  number  of  test  pins  have  been  presented. 

Some  of  the  different  characteristics,  such  as  tfie  use  of  latches  or  flip- 
flops,  occur  because  of  features  of  the  system  being  designed.  Other 
characteristics,  such  as  the  use  of  a  test  clock  or  a  level  test  signal,  are  design 
decisions  that  depend  on  many  factors.  Including  the  chip  technology,  the 
experience  of  the  designer,  the  relative  cost  of  Interconnect  and  logic,  the  level  of 
fault  coverage  and  diagnosis  desired,  etc.  There  does  not  exist  a  single  scan-path 
technique  that  Is  best  for  all  applications.  This  section  Introduced  the  various 
approaches  that  are  used  to  help  the  designer  make  an  informed  choice  of  which 
scan-path  technique.  If  any.  Is  best  for  his  application. 


E-23 


TESTABILITY/DIAGNCSTIC  DESIGN  TECHNIQUES 


APPENDIX  E 


FIGURE  12.  GENERAL  STRUCTURE  OF  CIRCUIT  USING  RANDOM-ACCESS  pCAN 
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FIGURE  13.  ADDRESSABLE  LATCH  WITH  COINCIDENT  SELECTION 


TESTABILITY/DIAGNOSTIC  DESIGN  TECHNIQUES 


APPENDIX  E 


4.1 .5  Scan  and  tha  TM  Bua 

As  can  be  seen  from  an  examination  of  the  TM  bus  specification  In 
Section  7,  this  bus  has  been  carefully  selected  by  the  VHSIC  Phase  2  Contractors 
to  be  compatible  with  both  the  scan  design  approach  and  the  signature  analysis 
approach  of  implementing  testability.  For  those  contractors  preferring  scan  design, 
there  Is  a  virtual  one  to  one  correspondence  between  the  functions  of  the  four  bus 
lines  and  the  four  lines  (maximum)  generally  required  by  scan  design.  Thus,  It  Is 
recommended  that  any  producer  desiring  to  utilize  scan  design  follow  closely  the 
specification  of  Section  7. 


4.1.6  Boundary  Scan 

The  scan-path  techniques  described  In  the  previous  sections  Improve 
testability  by  increasing  controllability  and  observability  through  better  Internal 
access  and  by  eliminating  the  necessity  of  sequential  circuit  test  pattern  generation. 
The  technique  described  in  this  section  Improves  testability  by  reducing  the 
requirements  placed  on  the  physical  test  equipment. 

The  general  I/O  scan-path  structure  Is  shown  In  Figure  14.  The  system 
latches  are  Implemented  in  an  LSSD-type  design  so  that  they  form  a  scan  path, 
called  Internal  scan  path,  or  ring,  for  test  purposes.  In  addition,  a  pair  of  scan-path 
latches  are  Introduced  for  each  I/O  bounding  pad.  These  I/O  latches  are  configured 
as  another  LSSD-type  scan  path,  called  external  scan  path,  or  ring. 

The  test  procedure  Is  very  similar  to  that  described  In  the  LSSD  structures 
section.  The  necessary  modlflcaticns  are  that  the  X|  values  are  scanned  In  via  the 
SDI  pin.  The  DMUX  control  must  be  set  to  direct  Its  Inputs  to  the  external  ring. 


The  Z  outputs  from  the  combinational  logic  must  be  clocked  Into  the 
external  ring  latches  that  are  then  shifted  out  via  the  SDO  pin. 

The  presence  of  the  external  scan  path  allows  a  chip  to  be  tested  through 
a  small  number  of  probe  pins:  seven  control  pins  plus  two  pins  for  power  and 
ground.  Another  feature  Is  that  this  structure  can  easily  be  modified  for  use  In  a 
built-in  self-test  configuration. 

4.1.7  Applicability  to  Design  Levels 

Scan  techniques  are  appropriate  for  use  at  the  component  level.  Both 
VHSIC  and  non-VHSIC  chips  are  currently  available  with  this  powerful  feature. 
Scan 
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RGURE  U.  GENERAL  STRUCTURE  CIRCUIT  USING  SCAN 
LATCHES  ON  INPUT/OUTPUT  PINS 


Is  also  a  very  powerful  tool  for  use  at  the  board  or  module  level.  Boundary  scan  has 
the  promise  of  being  applicable  at  the  box  or  subsystem  level  and  at  the  system 
level  Itself.  Although  its  use  at  these  higher  levels  Is  In  a  formative  state,  boundary 
scan  could  play  a  Key  role  in  the  Increased  BIT  capability  necessary  for  a  successful 
Implementation  of  two^level  maintenance. 

4.2  Signature  Analyals 

Normally  speaking,  signature  analysis  Is  a  technique  of  compressing  the 
sequential  digital  values  of  a  signal  to  be  evaluated  into  a  smaller  number  of  bits 
called  a  signature.  In  this  section,  signature  analysis  is  defined  broadly  as  a 
technique  which  utilizes  one  or  more  Linear  Feedback  Shift  Registers  (LFSR)  to 
generate  pseudo-random  stimuli  and  one  or  more  LFSR  to  compress  resultant 
patterns  and  compare  same  against  stored  known-good  results.  Positive  aspects 
are  the  small  amount  of  circuitry  required,  the  advantages  of  an  at-speed  test,  and 
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the  elimination  of  the  process  of  obtaining  logically  derived  test  vectors.  Negative 
aspects  are  possible  aliasing  problems  and  reduced  fault  coverage  In  certain  test 
situations. 


Techniques  for  data  compression  and  for  embedding  the  signature 
analysis  technique  In  a  module  are  described  In  the  paragraphs  to  follow.  For 
purposes  of  addressing  the  complete  problem  associated  with  testing,  this 
discussion  Is  aimed  at  the  task  of  incorporating  self  test  into  the  module.  Depending 
on  the  maintenance  concept  and  Its  Implementation  strategy,  some  or  all  of  the 
components  described  may  be  designed  into  other  modules  or  embedded  In 
external  automatic  test  equipment.  The  available  techniques,  If  not  their  relative 
advantages,  will  be  the  same. 

4.2.1  Stimulus  Qeneratlon 

Designing  a  module  to  provide  full  self>test  capability  requires  that  both 
stimulus  and  response  evaluation  be  provided  on  the  module.  Each  function  must 
be  Implemented  by  selecting  and  adapting  elements  from  among  the  available 
techniques.  These  techniques  are  described  below  In  separate  paragraphs. 

The  underlying  concept  of  signature  analysis  Is  that  of  the  ''toggling  line" 
(a  logic  node  that  changes  from  one  logic  state  to  another).  Only  a  limited  amount 
of  Information  can  be  derived  from  a  logic  node  that  never  changes  state  during  a 
particular  test  sequence.  It  doesn't  get  "exercised."  This  applies  to  nodes  on 
modules  as  well  as  the  logic  nodes  Internal  to  a  package  (1C).  On  the  other  hand,  If 
a  node  actively  changes  state  in  a  proper  manner  at  the  correct  time  for  that  circuit, 
valid  Information  and  confidence  result.  In  fact,  It  often  statistically  doesn't  matter 
very  much  "what"  caused  It  to  toggle  or  wiggle  for  It  to  provide  useful  diagnostic 
information.  However,  a  "truth  table"  exercise  on  the  components  Is  generally  more 
exhaustive  and  will  catch  a  greater  number  of  failures. 

The  signal  that  causes  the  node  to  toggle  Is  the  "stimulus."  In  self  test, 
the  stimulus  Is  supplied  by  the  product  itself.  By  doing  this,  a  controlled  environment 
can  be  created  wherein  selected  circuit  portions  can  be  tested  Independently  of 
others.  Additionally,  synchronization  and  measurement  Intervals  for  the  signature 
generator  must  be  controlled.  In  microprocessor  systems,  the  stimulus  needs  to  be 
nothing  more  than  a  program  (generally  In  ROM)  that  exercises  the  rest  of  the 
system.  Taking  advantage  of  the  data  manipulative  cnpabllltles  of  microprocessors, 
generating  good  stimulus  patterns  that  exercise  Individual  devices  in  the  module  Is 
sometimes  not  difficult,  It  Is  often  true  that  the  more  complex  the  system,  the 
greater  the  benefit  derived  from  using  signature  anaivsis 

For  modules  which  do  not  contain  microprocessors,  it  is  still  possible  to 
store  tost  patterns  on  a  ROM  and  to  apply  them  as  stimulus  to  the  remainder  of  the 
circuitry.  The  outputs  of  the  ROM  could  be  multiplexed  with  the  inputs  and  stimulus 
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test  points  In  a  manner  Illustrated  In  Figure  15.  This  arrangement  permits  any 
specific  Inputs  to  be  accommodated  on  a  module  and  to  be  used  to  generate  self¬ 
test  stimuli. 


CLK  RESET  SEL 


CIRCLE  INPUTS 
AND 

PACKAGE  INPUTS 


FIGURE  15.  TEST  ROM  STIMULUS 


A  major  disadvantage  of  saving  seif-test  patterns  on  ROM  Is  that  the 
number  of  packages  jlCs)  which  must  be  devoted  to  test  stimulus  Is  large,  This 
number  Is  as  sensitive  to  the  number  of  points  to  which  stimuli  must  be  sent  as  to 
anything  else.  Typical  ROMs  provide  8-pln  or  16-pin  outputs.  Thus,  as  more  points 
aro  required,  more  packages  are  needed.  One  alternative  Is  to  distribute  the  ROM 
outputs  to  multiple  points.  Multiplexing  or  shifting  of  the  ROM  outputs  can  be 
accomplished  by  various  methods.  Each  such  approach  limits  the  stimulus  either  as 
to  the  number  of  stimulus  test  points  which  can  change  status  In  a  test  sequence  or 
as  to  the  rate  at  which  the  test  can  be  carried  out. 

Another  method  of  generating  stimuli  is  to  use  a  binaiy  counter  to  apply  all 
2  to  the  nth  Input  combinations  to  the  (combinational)  circuit  being  tested.  This  is 
called  exhaustive  testing. 
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Exhaustive  testing  provides  a  thorough  test,  but  can  require  a  prohibitiveiy 
long  test  time  for  ciroults  with  20  or  more  inputs.  It  is  possible  to  reduce  the  test 
time  to  a  praotical  value  while  retaining  many  of  the  advantages  of  exhaustive 
testing.  The  method  Is  to  apply  alt  possible  inputs  to  portions  of  the  circuit  under 
test  rather  than  to  the  entire  circuit.  The  simplest  approach  Is  applloabla  to  circuits 
In  which  none  of  the  outputs  depends  on  all  of  the  Inputs. 

Most  combinational  networks  have  more  than  one  output.  In  many  cases 
each  of  the  outputs  depends  on  only  a  subset  of  the  Inputs.  For  example,  the  parity 
generator  network  of  the  Tl  SN54/74LSe30  has  23  Inputs  and  six  output  functions, 
but  each  output  depends  on  only  10  of  the  Inputs.  It  may  not  be  practical  to 
exhaustively  test  the  outputs  by  applying  all  combinations  of  the  network  Inputs. 
However,  It  may  be  possible  to  exhaustively  test  each  output  by  applying  all 
combinations  of  only  those  inputs  on  which  the  output  depends.  For  the 
SN74LS630,  each  output  can  be  exhaustively  tested  with  2  to  the  tenth  ■  1024  input 
patterns,  and  all  six  outputs  can  be  tested  one  after  another  with  (6)(1024)  ■  6144 
patterns.  In  fact,  for  this  circuit  It  Is  possible,  by  an  appropriate  oholos  of  Input 
patterns,  to  apply  all  possible  Input  combinations  to  each  output  concurrently  rather  , 
than  serially,  Thus,  with  only  1024  rather  than  (6)(1024)  tost  patterns,  each  output 
can  be  tested  exhaustively. 

This  method  of  reducing  the  number  of  stimulus  test  steps  required  for 
exhaustive  testing  may  not  be  applloabla  or  may  still  result  In  a  test  too  long  to  be 
practical.  Another  method  Is  required  for  these  oases.  That  method  Is  to  use 
stimulus  test  points  to  partition  the  circuit  In  several  ways.  In  each  partitioning,  each 
output  point  depends  on  only  some  input  points.  Thus,  for  each  partitioning  the  total 
number  of  steps  required  to  test  the  circuit  is  signifioantly  reduced.  More  than  one 
partitioning  may  be  required  to  test  all  the  gates  and  gate  inputs. 

Most  modern  circuitry  is  not  combinational.  Thus,  the  exhaustive  method 
of  testing  Is  not  applloabla.  In  these  oases,  stimulus  test  points  can  be  divided 
between  ROMS  for  driving  sequential  circuits  and  counters  for  exhaustively  testing 
the  combinatorial  portions.  This  approach  may  also  require  the  addition  of  gates  to 
separate  and  decouple  sequential  circuits  from  combinatlonaloircults. 

Stimuli  may  be  generated  randomly  rather  exhaustively.  For  methods 
which  use  this  approach,  the  word  random  Is  really  a  misnomer.  The  stimuli 
sequence  Is  always  the  same  and  can  be  described  by  some  generating  function.  It 
Is  called  random  because  the  generating  function  Is  so  complex  that  no  pattern  Is 
apparent.  Such  patterns  are  often  called  pseudorandom. 

The  most  common  hardware  approach  for  generating  pseudorandom 
patterns  Is  based  on  a  simple  circuit  called  an  autonomous  LFSR.  An  LFSR  Is  a 
series  connection  of  delay  elements  (D  flip-flops)  with  no  external  Inputs  and  with  all 
feedback  provided  by  means  of  exclusive-or  gates  (XORs).  A  four-stage  LFSR  Is 
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shown  in  tht  top  portion  of  FIgurs  16  and  th«  gensral  standard  form  of  LFSR  Is 
shown  In  tha  bottom  portion  of  FIgurs  16.  Ths  symbol  hi  In  FIgurs  18  indicatss  ths 
possible  prsssncs  of  a  fssdback  connsctlon  from  ths  output  of  each  stags.  If  hi,  ■ 

1 ,  thsrs  Is  fssdback  from  stags  I;  and  If  h|  -  0,  ths  stags  I  output  is  not  connsctso  to 
ths  XOR  fssdback  network.  Ths  LFSR  can  bs  spscifisd  by  just  listing  ths  values  of 
ths  h|  or  by  specifying  ths  generating  function  as  shown  In  Rgurs  16. 


Another  possible  realization  of  an  LFSR,  called  a  "modular  realization,"  Is 
shown  in  FIgurs  1 7.  Thsrs  are  as  many  XOR  gates  in  ths  modular  realization  as 
thsrs  are  fssdback  taps  In  ths  standard  circuit.  Ths  gates  are  placed  in  the 
"reverse"  positions  from  ths  locations  of  ths  fssdback  taps.  It  In  ths  standard  LFSR 
thsrs  are  m  "taps"  (Inputs  to  ths  XOR  network  generating  ths  fssdback  signal),  m  •  1 
twO'input  XOR  gates  are  required  If  an  Iterative  structure  Is  used  to  realize  ths  XOR 
network.  This  Is  ths  minimum  gats  realization,  it  Is  slower  than  a  tree  network, 
which  also  requires  m  •  1  gates,  but  has  a  delay  of  log  m  gats  propagations  rather 
than  m  •  1  gats  delays.  Ths  modular  circuit  also  requires  m  •  1  XOR  gates.  It  has  a 
delay  of  only  one  gate  propagation.  For  circuits  with  more  than  two  feedback 
signals,  faster  operation  always  results  with  the  modular  rather  than  the  standard 
LFSR. 


The  sequence  of  states  for  the  LFSR  of  Figure  16  Is  shown  In  Table  2. 
Note  that  the  sequence  repeats  after  IS  (2  to  the  4th  - 1)  clocks.  This  Is  the 
maximum  period  for  a  four*stage  LFSR;  the  alLzero  state  of  the  register  cannot 
occur  In  the  maximum'length  cycle  since  an  all-zero  state  always  has  a  next  state 
that  Is  also  all  zeros  due  to  the  use  of  XORs  to  form  the  feedback  signal.  In  general, 
the  maximum  period  for  an  n-stage  LFSR  is  2  to  the  nth  - 1 .  There  are  maximum- 
length  realizations  for  all  values  of  n.  The  generating  function  corresponding  to  a 
maximum-length  LFSR  is  called  a  primitive  polynomial.  Tables  of  primitive 
polynomials  can  be  found.  They  have  fixed  lengths  or  periods. 

One  period  of  the  output  sequence  produced  by  the  LFSR  of  Figure  16  is; 

(000  1  11  10  1  0  1  1  00  1) 

The  five-stage  LFSR  with  feedback  connections  given  by  H  -  (100101) 
has  the  following  output  sequence; 

(111110001101110101000010010110  0) 
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o(t)  <h^.  hj . hQ>  ■  <1.1,0.0.1> 

(q)  0«n<roUnq  funttloni  t(ii)  «  I 

a(HN)  A  o<HN-l)  A  «(t+M-a)  A  a<k+l)  A 


*»N-2 


N-1 

N-2 

>'N-t 

(b)  ObnvqUnq  funitlMi  t(x)  xl  Mcbulb  a  •(»+•<)  titobyt*  a 

riouM  t«.  rANOAM  roNM  or  aotonomous  UNiAR-motACx  iHrr  RC(MniR,OM  trwi 
(«)  rouR-rAoc  cMCuiri  (b)  N-rAot  enourr 
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TABLE  2 

STATE  SEQUENCE  FOB  PIQURE 16 


State 

Q1 

02 

03 

04 

0 

1 

0 

0 

0 

1 

1 

1 

0 

2 

1 

1 

1 

0 

3 

1 

1 

1 

1 

4 

0 

1 

1 

1 

S 

1 

0 

1 

1 

6 

0 

1 

0 

1 

7 

1 

0 

1 

0 

8 

1 

1 

0 

1 

9 

0 

1 

1 

0 

10 

0 

0 

1 

1 

11 

1 

0 

0 

1 

12 

0 

1 

0 

0 

13 

0 

0 

1 

0 

14 

0 

0 

0 

1 

15  -  Q 

1 

0 

0 

0 

4.2.2  Slgnatur*  Davalopmant 

A  taohniqu*  for  ganarating  stgnaturaa  It  batad  on  an  LFSR  In  which 
axclualva-or  gatat  ara  utad  to  control  tha  fatdback.  To  many  paopla,  this 
tachnlqua  Is  synonymous  with  signature  analysis.  Accordingly,  tha  oomprasslon 
coda  ganaratad  by  this  tachnlqua  Is  simply  oallad  tha  "slgnatura.*  An  axampla  of  a 
four>staga  LFSR  circuit  Is  shown  in  Rgura  18.  in  that  figura,  outputs  of  soma  of  tha 
flip-flops  provide  faadbaoK.  One  such  flip-flop  is  tha  first  one  (FF1)  and  one  it  tha 
last  one  (FF4),  Other  configurations  of  feedback  can  be  salactad  aa  wall  as  other 
flip-flop  counts. 

Two  wail  known  versions  ara  16  stages  long.  Theta  ara  tha  16-blt  Cyclic 
Redundancy  Check  (CRC-16)  in  which  tha  outputs  of  flip-flops  2,  15,  and  16  art  fad 
back  to  tha  input,  and  tha  Synchronous  Data  Link  Control  (SDLC)  coda  In  which  the 
outputs  of  flip-flops  5,  12,  and  16  ara  fad  back  to  tha  input.  Another  version,  which 
Is  used  by  Hewlett-Packard,  feeds  tha  outputs  of  flip-flops  7.  9,  12,  and  16  back  to 
tha  Input. 
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FIGURE  18.  FOUR-STAGE  LINEAR-FEED-BACK  SHIFT  REGISTER 


LIkf  slgnaturvs  ••(•otvd  for  th«  parity  tochniquos,  th«  LFSR  technique 
divides  the  poesible  Input  date  value  sequences  Into  different  sets.  The  number  of 
sets  depends  on  how  many  stages  of  flip-flops  there  are.  Signatures  can  be  used  to 
distinguish  between  any  two  data  value  sequences  which  are  in  different  sets,  but 
cannot  be  used  to  distinguish  between  data  value  sequences  In  the  same  set. 
Different  feedbacks  will  result  In  sets  with  different  related  characteristics.  Both  the 
CRC-16  and  SDLC  codes  have  sets  with  the  property  that  every  data  value 
sequence  In  a  given  set  will  have  the  same  parity.  The  code  selected  by  Hewlett- 
Packard  doea  not. 

The  LFSR  techniques  can  be  adapted  for  use  with  multiple  Input  data 
streams.  Such  an  approach  could  be  used  to  reduce  the  data  from  several  test 
points  to  one  value  which  can  be  used  for  module  screening.  It  can  also  support 
fault  Isolation  to  the  component  level  by  reducing  the  date  value  sequences  from  all 
the  outputs  of  a  package  to  one  signature  for  each  module.  In  effect,  one  signature 
Is  provided  to  check  each  package.  The  basic  circuit,  called  a  multiple-input  LFSR, 
Is  shown  In  Figure  1 9. 
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Car«  should  b«  tsKsn  In  how  trrors  will  propagats  onto  tha  Input  Unas  of 
multIpla-Input  LFSRa  baoausa  a  fallura  on  ona  input  (ollowad  by  a  failura  at  tha  naxt 
clock  on  tha  Input  antaring  tha  naxt  staga  flip-flop  will  axactly  cancal  out  and  rasult  In 
an  arronaous  Indication  that  tha  circuit  Is  corract.  This  typa  of  flaw  can  ba 
amalioratad  by  providing  inputs  only  to  non-ad)acant  flip-flops  or  slimlnatad  by 
separating  Inputs  with  flip-flops  that  output  to  feedback  taps. 

Use  of  signature  analysis  to  support  built-in  self-test  of  modules  can  only 
be  accomplished  if  the  circuit  to  which  It  Is  to  be  applied  has  several  testability 
prop>ertia8.  Among  those  properties  are; 

0  The  data  changes  at  all  measurement  points  must  be  synchronous  with 
one  Clock  line. 

0  There  must  be  no  feedback  loops  or  there  must  be  methods  of  breaking 
feedback  loops  for  testing. 
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0  It  must  b«  possible  to  isolate  the  circuit  from  all  Input  circuits  for 
purposes  of  testing. 

0  There  must  be  a  method  of  forcing  the  circuit  to  a  known  state  at  the 
beginning  of  a  test  stimulus  sequence. 

0  There  must  be  a  known  value  at  every  measurement  point  for  each 
clock  time  during  the  test  stimulus  sequence.  Particular  concern  must 
be  shown  for  floating  bidirectional  lines. 

0  There  must  be  methods  of  disconnecting  buses  onto  which  the  outputs 
of  several  packages  are  put.  The  disconnections  must  be  at  enough 
points  so  that  the  fault  Isolation  ambiguity  group  size  requirements  are 
met.  If  this  bus  also  serves  for  data  or  control  Input  to  the  packages, 
each  separated  segment  must  be  provided  with  stimulus  data. 

4.2.3  Signature  Anslysla  and  the  TM  Bua 

Signature  analysis  can  be  used  to  provide  self  test  for  a  module  and  to 
permit  fault  Isolation  to  the  component  level  under  control  of  an  online 
microprocessor  or  an  external  ATE.  This  capability  can  only  be  provided  by  making 
a  large  amount  of  Information  available  at  an  edge  connector  and  providing  a 
significant  amount  of  control  for  developing  that  Information,  The  TM  bus  Is  an 
effective  and  natural  way  of  meeting  these  needs  without  using  a  large  number  of 
Input/output  lines. 

Depending  on  the  system  requirements  and  the  module  capabilities, 
evaluation  of  signatures  may  take  place  on  the  module  or  It  may  be  done  outside  of 
the  module.  For  purposes  of  simplicity,  the  case  where  signature  evaluation  Is  done 
outside  the  module  (either  by  a  system  microprocessor  or  by  an  ATE)  Is  described. 
The  circuit  components  needed  for  this  case  are  shown  In  Figure  20, 

In  Figure  20  there  Is  no  requirement  tor  an  embedded  microprocessor 
controller.  Such  a  component  Is  not  precluded  and  If  It  Is  available,  It  can  be  put 
between  the  TM  BUS  CONTROL  circuitry  and  the  other  self-test  circuitry  to  expand 
and  automate  the  testing  services  provided. 
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Th«  TM  BUS  CONTROL  circuitry  is  ths  central  control  olomant  for  self* 
t«8t  capabilltlas  whan  thara  la  no  ambaddad  mlcroprocaasor.  In  this  role,  Its 
function  Is  to  accapt  tast  commands  from  tha  TM  bus  and  Implamant  tham  through 
tha  salMast  circuitry.  Thara  ora  only  thraa  typas  of  commands  which  ara  nacassary; 

0  Transfar  data  to  tha  stimulus  tast  points 

0  Run  tha  salf-tast  stimulus 

0  Collact  and  ratum  tha  generated  signatures  over  the  TM  bus 

In  Figure  20,  the  stimulus  test  point  control  circuitry  and  stimulus 
generation  circuitry  are  shown  as  separate  functions.  One  of  them,  the  stimulus  test 
point  control,  reconfigures  the  circuit  for  testing  and  selects  the  measurement  test 
point  whose  signature  Is  to  be  made  available  for  evaluation.  The  other  stimulus 
function,  tha  stimulus  generation  circuitry,  consists  of  ROMs,  Binary  Counters,  and 
LFSRs  as  required  to  generate  a  stimulus  signal. 


E-36 


I  TESTABILfTY/DIAGNOSTIC  DESIGN  TECHNIQUES  APPENDIX  ^ 

Tho  stimulus  control  block  Is  described  In  Figure  20  as  being  serial  to 
parallel  shift  registers.  It  Is  not  mandatory  that  this  technique  be  used  to  accomplish 
the  function  of  setting  the  values  of  stimulus  test  points.  But  the  technique  does 
offer  advantages  In  this  situation.  One  advantage  Is  that  the  data  to  be  entered  can 
be  sent  directly  (through  a  buffer)  from  the  TM  BUS  MASTER  DATA  line  Into  the 
shift  register.  This  reduces  the  amount  of  processing  required  of  the  TM  BUS 
CONTROL  circuitry.  Another  reason  Is  that  this  method  requires  fewer 
Intercoriiiections  within  the  module  than  would  be  required  by  demultiplexing  and 
decoding  tochniquer  This  may  reduce  the  board  area  requirements  of  the  test 
circuitry.  A  final  advv  .tage  Is  that  some  of  the  serial  to  parallel  shift  registers  may 
be  Incorporated  within  semi>custom  or  custom  packages  (iCs)  without  requiring  a 
large  number  of  package  Input/output  pins. 

The  stimulus  generation  otroultry  needs  to  be  treated  differently.  It  must 
generate  a  sequence  of  test  steps  which  will  expose  any  faults  that  exist  at  one  of 
the  teat  measurement  points.  One  or  more  of  the  approaches  deocribed  In 
paragraph  4.2.1  would  be  used  (I.e.  ROM  sequences,  binary  counters  or  LFSRs).  It 
must  operate  dynamically  along  with  a  synchronizing  clock  and  provide  start  and 
stop  signals  for  the  signature  generation  circuit. 

Only  one  signature  generator  Is  shown  In  Figure  20.  More  signal 
generators  could  be  used  or  a  multiple  input  signal  generator  could  be  used.  The 
approach  depicted  utilizes  a  multiplexer  and  requires  the  minimum  amount  of 
circuitry  for  testing.  It  will  support  as  many  test  points  as  may  be  needed.  In  any 
case,  only  one  or  possibly  a  few  signatures  can  be  developed  (or  each  stimulus  test 
sequence.  This  data  Is  made  available  to  the  TM^BUS  CONTROL  circuitry  to 
transmit  to  the  test  control  microprocessor  or  ATE. 

External  to  Figure  20,  but  important  to  the  overall  approach,  Is  a 
microprocessor  or  ATE  which  controls  the  utilization  of  the  test  circuitry  embedded  In 
the  module.  It  must  control  the  module  resident  test  circuitry  to  set  It  (or  testing,  run 
a  stimulus  test,  and  collect  the  resultant  signatures.  It  must  also  determine  which 
signatures  to  collect  and  must  evaluate  those  signatures.  Finally,  it  must 
communicate  the  overall  results  to  whoever  Is  responsible  for  tei»t  and  maintenance. 

4.2.4  Applicability  to  Design  Levels 

Signature  analysis  techniques  are  currently  available  in  various  VHSIC 
chips.  This  technique  Is  also  appropriate  at  the  board  or  module  level,  It  has  been 
successfully  employed  In  this  role  for  many  years.  Applications  at  higher  levels  are 
theoretically  possible  but  a  review  of  current  literature  has  uncovered  little. 
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4.3  Wraparound  Tachniquaa 

4.3.1  Ganaral 

The  wraparound  technique  has  become  a  standard  In  the  testing  of 
microprocessor  based  systems.  The  system  to  be  tested  can  consist  of  a  single 
microprocessor  based  board  or  a  system  made  up  of  many  such  boards.  The  start 
of  the  test  consists  of  determining  whether  or  not  the  core  of  the  microprocessor 
based  system  Is  operational.  This  might  be  done  in  some  Instances  through  the  use 
of  hardware  redundancy.  As  the  tested  core  Is  found  to  bo  operational,  the  process 
expands  further  out  through  the  logic,  continually  building  upon  the  operational  core. 
A  failure  at  any  point  must  provide  sufficient  data  for  diagnosis.  As  the  tested  core 
expands,  a  transition  to  other  test  resources  occurs. 

At  the  very  heart  of  the  core,  hardware  techniques  are  used.  As  the 
operational  core  builds,  firmware  becomes  the  medium.  As  the  growth  builds 
further,  software  In  the  semiconductor  memory  of  the  system  would  become  the 
med  n.  After  It  is  determined  to  be  operational,  the  move  would  be  out  Into  some 
type  f  bulk  storage  medium.  The  idea  Is  to  transition  as  quickly  as  possible  along 
this  route  because  as  the  move  transitions  from  hardware  to  firmware  to  software, 
the  cost  of  the  test  function  Is  reduced. 

A  typical  microprocessor  based  system  is  depicted  In  Figure  21.  The 
system  consists  of  a  microprocessor,  an  address  bus,  a  data  bus.  Read  Only 
Memory  (ROM)  associated  with  operational  software,  and  Random-Access  Memory 
(RAM)  which  is  provided  for  user  software.  There  is  normally  a  programmable 
inter'  iCe  assembly  associated  with  data  coming  out  the  microprocessor  system. 
Signals  coming  out  of  the  microprocessor  pass  through  this  Interface  assembly, 
through  circuitry  associated  with  these  outputs,  and  out  to  the  operational  circuitry. 
The  signals  coming  back  from  the  operational  circuitry  come  through  Input  lines  and 
through  other  Programmable  Interface  Assemblies  (PIA)  back  Into  the 
microprocessor  system.  As  mentioned,  the  operational  circuitry  might  be  self 
contained  on  the  board  housing  the  microprocessor  itself,  or  It  may  be  on  one  or 
more  additional  boards  In  the  system. 

4.3.2  Core,  ROM,  RAM  Testing 

The  core  test  would  begin  by  performing  some  very  rudimentary  routines 
with  the  microprocessor.  For  example,  data  may  bo  moved  from  one  register  to 
another.  A  simple  "ADD"  routine  might  be  performed  where  two  numbers  are 
summed  and  compared  against  known-good  results  stored  In  ROM.  After  this  core 
capability  Is  validated,  the  next  step  would  be  to  move  onto  the  testing  of  read  only 
memories,  A  simple  test  which  can  be  used  to  ascertain  whether  or  not  the  ROM  is 
operating  correctly  would  be  a  checksum.  This  procedure  can  be  done  by  the 
microprocessor  Itself  and  requires  little,  If  any,  additional  circuitry  for  the  test 
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purpose.  However,  there  Is  the  possibility  of  conipensating  errors  with  the 
checksum  technique.  A  more  elaborate  test  might  be  a  Cyclic  Redundancy  Check 
(GRC).  This  type  of  check  is  time-dependent  and  will  weed  out  that  class  of  errors. 
However,  It  takes  additional  hardware  to  perform  this  particular  function.  Therefore, 
a  trade-off  must  be  performed  to  ascertain  whether  or  not  the  additional  hardware  is 
worthwhile  In  order  to  catch  tlme<dependent  type  faults. 

After  the  microprocessor  core  Is  deemed  operational  and  the  ROM  checks 
have  been  done,  checks  on  the  system  RAM  can  be  Initiated.  There  are  standard 
patterns  that  have  become  available  throughout  industry  known  as  QalPats  or 
galloping  patterns,  walking  ones  and  wolking  zeros,  checkerboards.  Inverted 
checkerboards,  and  other  standard  tests  of  this  type.  The  process  Is  to  write  to 
memory  and  than  to  read  this  data  back  to  determine  whether  or  not  the  memory 
functioned  correctly.  Again,  this  can  be  done  on  a  software  basis  or  It  can  be  done 
with  hardware.  A  software-based  test  Is  necessarily  slower  because  the 
microprocessor  is  in  the  loop.  A  hardware-based  test  can  be  much  faster  because  it 
can  run  at  the  speed  at  which  the  memory  can  cycle,  without  being  constrained  by 
ne  Instruction  time  of  the  microprocessor.  Again,  a  trade-off  Is  necessary.  If  speed 
is  of  the  essence,  then  one  must  pay  for  the  hardware  to  do  the  faster  tests.  If  the 
hardware  penalty  is  too  much  to  pay,  then  the  software-based  test  would  be  a  good 
alternative,  although  It  will  take  longer  to  perfonTt, 


MICROPROCESSOR 


ADDRESS  BUS 


DATA  BUS 


FIGURE  21 .  TYPICAL  MICROPROCESSOR-BASED  SYSTEM 
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4.3.3  ProoMtor  ControllMi  Gating 

At  this  point  in  tima,  if  the  microprocessor  core  Is  deemed  to  be 
operational  and  the  ROM  and  RAM  are  operational,  a  very  powerful  core  of  test 
capability  exists.  The  next  step  Is  to  check  the  remainder  of  the  circuitry,  which 
might  be  only  a  relatively  small  amount  on  a  single  board  on  which  the 
microprocessor  Is  contained,  or  It  might  be  a  larger  system  consisting  of  many 
boards.  To  do  this,  a  closad-loop  system  must  be  created  so  that  stimulus  test 
vectors  stored  in  an  area  of  ROM  can  be  used  by  the  system  microprocessor  to 
drive  out  through  the  interface  assembly  end  the  circuitry  associated  with  output 
lines  to  stimulate  the  rest  of  the  operational  circuitry.  Processor  controlled  gating 
must  be  Included  In  the  system  In  order  to  take  that  data  and  wrap  It  around  so  that 
a  closed  loop  can  be  created  (refer  to  Figure  22).  This  allows  the  resultant  test 
vectors  to  come  back  through  the  circuitry  associated  with  output  lines  so  that  the 
microprocessor  can  effect  a  comparison  against  known-good  test  vectors  also 
stored  in  ROM.  The  basic  Idea  of  this  particular  test  philosophy  would  be  to  drive 
out  the  stimulus  test  vectors,  toggle  the  various  nodes  In  the  operational  circuitry 
looking  for  the  classical  stuck  at  one  and  stuck  at  zero  faults,  and  to  wrap  these 
vectors  around  so  that  they  find  their  way  back  to  be  compared  by  the 
microprocessor  against  stored  known-good  resultant  test  vectors.  If  each  one  of 
those  closed  loops  Is  indeed  operational,  one  and  only  one  known>good  vector  can 
be  the  result  In  each  Instance. 

This  type  of  bullt-ln  test  or  seif  test  Is  a  very,  very  powerful  technique  and 
has  become  a  standard  In  the  industry.  A  relatively  small  amount  of  test-oriented 
ROM  need  be  included  in  a  system  for  test  purposes.  Estimates  on  the  processor 
control  gating  range  from  S  to  15  percent  of  the  available  real  estate  in  order  to 
effect  the  wrap  around.  Of  course,  it  all  depends  on  an  operational  core.  In 
summary,  the  technique  Is  to  first  ascertain  whether  or  not  the  operational  core  is 
working,  then  to  check  key  Items  such  as  system  ROM  and  RAM,  and  then  after 
having  ascertained  whether  or  not  that  operational  core  is  functioning  correctly,  to 
use  that  operational  core  as  essentially  a  tester  to  check  the  remainder  of  the 
circuitry  In  the  system. 

This,  of  course.  Is  a  non-real-time  type  of  test.  When  it  Is  being 
conducted,  the  system  is  not  performing  Its  system  purpose.  It  Is  not  a  concurrent 
or  real-time  test,  nor  does  It  deal  with  the  analog  testing  problem.  It  Is  essentially  a 
digital  technique.  There  is  always  the  necessity  of  a  trade-off  between  how  much  of 
the  testing  Is  done  with  hardware  dedicated  to  that  purpose  (e  g.,  the  CRC  or  the 
QalPat  generators  and  monitors)  and  how  much  Is  software-based.  In  a  more 
software  Intensive  test,  the  duration  Is  longer  if  It  Is  software-baserl,  however,  there 
is  much  less  of  a  penalty  from  a  hardware  standpoint.  The  generation  of  the  test 
vectors  for  the  checking  of  the  operational  hardware  must  be  derived  via  standard 
techniques.  Such  techniques  Include  digital  logic  simulators,  automatic  test  pattern 
generators,  and  the  like.  However,  this  Is  a  one-time  development  and  much  of  the 
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CIRCUITRY  ASSOCIATED  CIRCUITRY  ASSOCIATED 

WITH  WITH 

OUTPUT  UNES  INPUT  UNES 


nOURE  22.  TEST  DATA  WRAPAROUND 


softwirt  may  alraady  ba  avallablt  via  tha  oparatlonal  aystam  naads.  Tharafora,  tha 
cost  assoclatad  with  it  should  not  ba  ovarly  savara. 

4.3.4  Applicability  to  Daaign  Lavala 

Tha  wrap-around  tachniqua  is  appropriata  at  tha  board/modula  or 
aubsystam  laval.  As  long  as  a  mioroprocassor  or  microprocassors  affaot  a  givan 
amount  of  cirouitry,  tha  tachniqua  is  valid  whathar  the  said  circuitry  is  physically  on 
a  singla  board/moc  jia  or  on  many  boards/modulas  (I.e.,  a  subsystem). 

4.4  Analog  Tachniquaa 

4.4.1  Qanaral 

Many  alaotronic  systems  combine  analog  and  digital  circuitry.  Tha  analog 
portion  of  these  systems  may  range  from  tha  DC  to  Radio  Frequency  (RF)  and 
microwave  mixing  and  signal  down  conversion.  Mechanical  or  environmental 
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signals  (e.g.,  tamperature  monitors.  Infrared  sensors,  etc.)  may  also  be  Included.  In 
general,  analog  fault  types  and  symptoms  may  be  more  complex  than  their  digital 
counterparts.  Although  faults  can  be  modeled  as  simple  shorts  or  opens,  the 
impact  of  some  analog  shorts  or  opens  may  be  marginal  and  may  not  cause  a 
noticeable  degradation  of  operational  performance  under  normal  conditions.  This 
contrasts  with  digital  circuitry  where,  with  enough  patterns,  a  fault  will  eventually 
propagate  to  cause  a  clearly  incorrect  output.  Analog  signals  may  have  an  Infinite 
number  of  values  within  a  given  range,  while  digital  signals  have  a  finite  set  of 
values  for  each  given  node  at  each  point  in  time. 

The  major  difficulty  In  testing  analog  circuits  Is  not  the  number  of  variables 
that  need  to  be  tested,  but  the  variation  in  signal  parameters.  Digital  signals  have  a 
set  clock  frequency  and  set  voltage  levels  where  analog  signals  may  constantly  vary 
In  frequency  levels  and  may  consist  of  multiple  complex  signals  modulated  onto  a 
carrier.  Failure  modes  causing  marginal  out-of-toleranoe  conditions  may  not  be 
detected  because  subsequent  stages  may  filter,  compensate  or  mask  this  condition. 

With  a  different  Input  signal  (e.g..  weaker  but  still  within  specification),  the  fault  may 
have  a  much  greater  Impact  on  the  output  signal  quality.  The  Impact  of  a  falling 
component  may  not  be  detected  until  one  or  more  stages  after  the  actual  fault.  This 
leads  to  difficult  Isolation  with  the  risk  of  tfte  fault  being  perceived  as  a  false  alarm, 

As  BIT  detection  requirements  approach  100  percent  of  all  possible  faults, 

BIT  test  thresholds  must  be  set  closer  to  the  operational  limits  of  a  parameter  In 
order  to  obsen/e  subtle,  second-order  faults.  This  increases  the  probability  that  the 
BIT  may  Indicate  a  fault  due  to  transient  noise  or  to  measurement  error  when.  In 
fact,  no  actual  fault  exists.  Thus,  increased  BIT  coverage  can  lead  to  Increased 
false  alarm  rates.  Current  applications  Indicate  the  future  of  analog  testability  as  a 
merging  of  digital  overhead  with  well-partitioned  analog  functions. 

Virtually  all  of  the  techniques  previously  discussed  (such  as  scan 
techniques,  signature  analysis,  wrap  around,  etc.,)  are  inherently  digital  In  nature. 

None  has  any  real  applicability  In  the  analog  world.  As  much  as  the  use  of  digital 
circuitry  has  continued  to  expand,  there  Is  probably  some  15  to  25  percent  of  the 
circuitry  that  is  still  In  the  analog  domain. 

4.4.2  Active  Versus  Passive 

Analog  techniques  can  be  either  active  or  passive  In  nature.  Active 
stimulus  injection  is  a  more  thorough  test,  in  general,  because  a  higher  fault 
coverage  can  generally  be  achieved  with  the  Injection  of  active  stimuli.  However, 
passive  monitoring  has  the  advantages  of  being  less  complex  In  nature  and, 
therefore,  less  costly  and  less  interfering.  The  Interference  factor  refers  to  the 
situation  that  if  the  test  circuitry  has  the  ability  to  actively  Inject  stimuli  during  a  test 
sequence,  there  Is  always  the  chance  that  the  test  stimuli  can  be  inadvertently 
Injected  during  system  operation.  This  would,  of  course,  be  very  Interfering  In 
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naturt.  The  tredt'Off  between  active  stimulus  Injection  and  passive  monitoring  Is 
essentially  a  trade*off  that  depends  upon  how  much  test  hardware  can  be 
accommodated  and  what  degree  of  fault  coverage  Is  necessary  for  that  particular 
system. 


4.4.3  Conversion  to  Digital  Format 

Today  most  analog  circuitry  Is  not  found  in  a  stand-alone  configuration, 
Much  of  It  Is  found  In  so  called  ’’hybrid”  circuits  where  there  are  both  analog  and 
digital  circuitry.  In  this  case,  It  Is  very  helpful  In  most  Instances  to  convert  the  analog 
signals  to  a  digital  form  as  quickly  as  possible.  This  Is  because  there  Is  a  very  large 
probability  that  there  Is  a  microprocessor  In  the  digital  part  of  the  circuitry  which  Is 
being  utilized  to  affectively  handle  the  digital  test  requirements.  By  taking  the 
analog  circuitry  and  converting  its  Information  Into  a  digital  format,  all  signal 
processing  can  be  done  In  a  digital  mode.  Therefore,  the  same  microprocessor  can 
be  used  to  set  limits,  modify  limits,  and  therefore  cause  the  analog  circuitry  to  be 
accommodated  In  much  the  same  flexible  fashion  as  the  digital.  It  also  contributes 
to  the  Intelligent  BITconcept  where.  If  a  failure  occurs,  the  microprocessor  can 
ascertain  that  fact  and  return  to  test  the  suspected  part  of  the  circuitry  a  number  of 
times.  This  cyclic  concept  Is  used  to  ascertain  whether  the  failure  was  merely  a 
transient  or  whether  It  was  Indeed  a  hard  failure.  In  short,  the  analog  approach  most 
often  recommended  Is  to  convert  such  signals  to  the  digital  format  as  quickly  as 
possible.  This  allows  limits  to  be  set  and  modified  under  control  of  the  digital  self¬ 
test  or  bu)lt-ln  test  circuitry.  It  also  allows  all  of  the  data,  whether  It  be  analog  or 
digital,  to  be  processed  In  the  same  fashion.  This  approach  supports  the  overall 
concept  of  Intelligent  BIT. 

4.4.4  Applicability  to  Dealgn  Levels 

The  analog  techniques  discussed  are  appropriato  at  various  levels  from 
the  board/module  upward.  Little  analog  capability  exists  at  the  component  level. 
Most  of  the  Industry  effort  to  date  has  been  In  the  digital  arena;  much  remains  to  be 
accomplished  In  the  analog. 

4.5  Concurrent  Teohniques 

4.5.1  General 

All  of  the  techniques  discussed  heretofore  cannot  be  considered  as 
concurrent  In  nature.  For  example,  when  scan  dealgn,  signature  analysis,  or  wrap¬ 
around  techniques  are  being  employed,  the  prime  system  function  cannot  be 
simultaneously  executed.  These  types  of  tests  can  only  be  done  In  non-real  time 
when  the  system  Is  not  doing  Its  prime  purpose.  These  techniques  are  also  digital  In 
nature  and  do  not  deal  effectively  with  analog  circuitry.  Another  common  built-in  test 
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tftchniqut  injtott  a  Known  signal  Into  tha  oparatlonal  circuitry  and  comparts  the 
aventual  rasult  to  a  Known<good  result. 

In  summary,  whan  dealing  with  concurrent  tasting  or  with  analog  circuitry, 
most  of  the  previous  techniques  are  not  applicable.  Concurrent  tasting  can  be 
either  passive  or  active  In  nature.  A  passive  approach  would  merely  use  monitoring 
circuits  to  ascertain  whether  or  not  the  correct  signal  was  present  at  various  stages. 

An  active  circuit  would  require  an  injection  of  a  stimulus  and  then  a  subsequent 
measurement.  The  latter  would  be  done  on  a  time-shared  basis,  so  as  not  to 
interfere  with  concurrent  system  operation. 

There  are  various  techniques  which  are  concurrent  In  nature  and  have 
been  used  In  Industry  for  many  years.  Parity  Is  such  a  technique.  Parity  can  be 
used  to  ascertain  whether  or  not  a  bit  has  been  dropped  In  the  transmission  of  a 
code  or  whether  a  bit  has  been  injected  due  perhaps  to  noise.  Parity  Is  Indeed  a 
concurrent  type  test.  Residue  codes  are  another  example  of  on-line  or  concurrent 
testing.  Residue  coding  uses  duplicate  circuitry  of  a  much  simpler  design  to  do  a 
concurrent  operation  so  that  a  check  can  be  made  on  the  residue  of  the  signals  In 
question  (Refer  to  Figure  23),  This  allows  a  concurrent  check  with  a  high  degree  of 
confidence.  If  the  secondary  circuit  determines  something  Is  wrong,  there  Is  a  good 
chance  the  primary  circuit  has  Indeed  malfunctioned. 

Other  examples  of  concurrent  testing  Include  the  M  out  of  2M  code  where 
each  2M  bit  code  must  have  exactly  M  logic  one  bits.  This  technique  requires  a 
specific  number  of  ones  to  be  used  In  each  code  word.  This  results  In  some  of  the 
codes  being  valid  and  some  Invalid,  so  that  dropped  bits  or  extra  bits  injected  by 
noise  can  be  detected.  One  negative  aspect  is  that  many  normally  valid  codes  are 
no  longer  usable.  For  example.  In  a  3  out  of  6  code,  you  would  normally  have  2  to 
the  6th  power  or  64  legal  combinations.  With  this  particular  approach  there  are  only 
20  legal  combinations. 

Other  concurrent  techniques  include  the  use  of  a  watchdog  timer  which 
closes  the  toop  in  signals  that  are  transmitted  between  a  control  system  and  any  of 
Its  peripheral  devices  (Refer  to  Figure  24).  In  other  words,  when  information  Is  sent 
from  the  CPU  to  a  peripheral  or  visa  versa,  a  free  running  counter  Is  Initiated.  If  the 
receipt  of  signal  Is  not  acknowledged  at  the  receiving  end  within  a  certain  amount  of 
time,  an  interrupt  Is  generated  which  Informs  the  operator  that  the  closed  loop  has 
been  broken. 

There  are  many  additional  codes  that  are  of  the  fault-tolerant  category. 
There  are  many  error  correcting  and  error  detecting  codes  that  are  used  within 
industry.  The  Hamming  code  is  a  good  example  of  one  which  Is  covered 
extensively  In  the  literature.  Such  codes  allow  continued  correct  operation  In  the 
presence  of  solid  faults  and  during  transient  disturbances.  The  penalty  Is  that 
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noURE  23.  RESIDUE  COOES 


TIME-OUT  COUNT 


1 

INTERRUPT 


nOURE  24.  WATCHDOG  TIMER 
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additional  hardwara  la  nacaaaary  In  ordar  to  provida  this  arror  datacting  and 
corracting  capability. 

It  is  vary  difficult  to  do  concurrant  tasting  without  tha  prasanca  of  tast 
circuitry  In  tha  oparatlonal  systam.  If  it  Is  an  airborna  systam,  for  axampla,  tha  tast 
circuitry  must  ba  small  and  ilghtwalght  and  yat  vary  powarful.  To  data,  having  tast 
capability  that  Is  small  enough,  light  enough,  and  yat  powarful  enough  to  do 
concurrant  tasting  has  bean  extremely  difficult.  Today  there  are  new  techniques 
which  can  make  this  possible. 

Standard  architectures  have  bean  developed  that  can  than  ba  made 
much  smaller  and  much  lighter  via  tha  use  of  ASIC  technology.  Tha  key  Is  to  coma 
up  with  standard  channels  of  tast  alactronles  so  that  once  this  reduction  in  size  Is 
affected,  It  can  merely  ba  replicated  for  however  much  capability  Is  necessary.  One 


4.5.2  PauN-Tolaranl  Daalgn 
4.S.2.1  Oanaral 


For  a  circuit  to  ba  fault  tolerant,  it  must  Implement  soma  technique  for 
Identifying  faulta  and  provida  soma  method  of  generating  tha  correct  results  daapita 
any  faults  which  have  been  Identified.  Theta  design  elements  are  part  of  fault- 
tolerant  daaigna  at  every  level  of  a  system  Including  circuits  within  custom  or  semi- 
custom  packages  (ICt),  circuits  contained  within  a  module,  and  circuits  Implemented 
on  several  modules  within  a  system  or  subsystem. 


(FIGURE  26  HAS  BEEN  WITHDRAWN) 
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B«oau8«  fault  tolaranoa  utilizat  taohniquas  for  idantifying  faults,  it  is  a 
propar  oonoarn  of  tha  tastabillty  dlsclpllna.  Howavar,  thara  Is  a  diffaranoa  In 
amphasis  •  a  majority  of  tha  taohniquas  Implamantad  for  tha  tastabillty  dlsclpllna 
hava  traditionally  baan  for  ofMlna  tast  and  onollna  tast  during  parlods  whan  tha 
systam  Is  not  baing  usad.  whila  tha  majority  of  tha  taohniquas  Implamantad  for  fault- 
tolarant  dasign  ara  for  uaa  during  tha  mission  Itsalf.  Thasa  taohniquas  must  ba 
aotiva  and  affactiva  during  tna  mission. 

In  addition  to  tha  Idantifioatlon  of  faults,  fault-tolarant  dasigns  must  provida 
soma  mathod  of  ganarsting  tha  oorraot  rasult  daspita  tha  fault.  Thara  ara  thrsa 
basic  mathods: 

0  Provida  radundant  circuitry 

o  Provida  partially  radundant  drouitry 

0  Provida  a  mathod  of  retrying  tha  affaotad  task  (for  non  permanent 
faults). 

Whan  oomplata  redundancy  Is  provided,  tha  circuitry  will  taka  tha  form 
Illustrated  In  Figure  26  or  If  tha  fault  idantifioatlon  prooasa  Is  based  on  a  "voting” 
arrangamant,  It  will  taka  tha  form  Illustrated  in  Figure  27. 

In  Rgura  26.  tha  selection  of  which  output  to  uss  is  based  on  tha  output  of 
tha  fault  Identification  circuit.  This  circuit  could  ba  placed  between  tha  primary 
circuit  and  tha  multiplexer.  In  that  case,  it  could  return  processing  to  tha  primary 
circuit  If  tha  failure  proves  transitory.  In  most  oases,  tha  Initial  failure  would  make 
tha  primary  circuit  suspect  and  using  tha  secondary  circuit  would  ba  preferred.  Tha 
advantage  of  tha  placement  of  tha  fault  Identification  circuit  shown  In  Figure  26  Is 
that  It  can  ba  usad  to  Identify  tha  axistanoa  of  failures  In  both  tha  primary  and 
secondary  circuits.  To  do  this,  it  must  use  tha  fact  that  a  primary  circuit  failure  Is 
ramambarad  for  controlling  tha  multiplaxar.  Thus,  all  tha  Information  Is  available 
to  determine  whether  a  new  failure  Invalidates  tha  last  radundant  circuit. 

In  Figure  27,  tha  fault  redundancy  Is  controlled  by  voting  circuits.  These 
circuits  in  affect  compare  signals  and  select  tha  ones  which  match.  Tha  comparison 
process  therefore  must  yield  status  information  necessary  for  later  repair. 

One  form  of  partial  redundancy  of  a  circuit  is  to  provida  complete 
redundancy  to  subsets  of  that  circuit.  This  form  of  partial  redundancy  may  ba 
selected  to  make  use  of  tha  fact  that  Identification  of  failures  is  easier  for  the  subset. 

Partial  redundancy  could  also  be  usad  to  make  the  circuit  more  fault 
tolarant.  Tha  approach  for  doing  this  is  shown  In  Figure  28.  Tha  top  diagram  of  that 
figure  shows  a  circuit  not  using  partial  redundancy.  Any  of  the  pairs  of  failures 
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FIGURE  26.  0(AMRI£  ARGHITICTURE  FOR  FAULT  TOLERANT  aRCUIT 


FIGURE  27.  EXAMPLE  ARGHrTECIURE  FOR  FAULT-TOLERANT  CIRCUIT 
USING  VOUNG  ARRANGEMENT 
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XI  •X2,  XI  *¥2,  Y1«X2,  Y1-Y2  will  oauM  tha  oomplata  circuit  to  fall.  In  tha  bottom 
diagram,  only  tha  pairs  of  falluras  XI •X2  or  Y1-Y2  will  causa  a  oomplata  circuit 
fallura.  Tha  rasult  Is  that  mora  faults  ara  tolaratad. 

A  disadvsntaga  of  tha  partial  radundancy  approach  Is  that  an  additional 
multiplaxar  (MUX)  and  Fault  Isolation  (FI)  circuit  Is  rsquirad.  Tha  rallablllty  of 
thasa  Itams  must  ba  taKan  Into  account  In  salacting  tha  ovarall  dasign  approach. 

Anothar  form  of  partial  radundancy  Is  tha  circuitry  usad  to  support  Error 
Corracting  Coda  (ECC)  strataglas.  This  typa  of  partial  radundancy  Is  primarily 
rastrlctad  to  data  transmission  and  data  storaga/ratrlaval  circuits.  In  most  such 
oasas,  tha  falluras  baing  addrassad  ara  "soft."  That  is,  thay  ara  produoad  by 
random  conditions  such  as  nolsa,  radiation,  ate.,  on  tha  circuits  or  transmission  linas 
Involvad.  Thus,  a  fallura  is  not  in  and  of  Itsalf  a  raason  for  circuit  repair.  Howavar,  it 
Is  possibla  for  tha  data  from  ona  mamory  bit  to  ba  parmanantly  low.  Tha  circuitry 
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8«nalng  and  oorrtoting  tha  trrore  may  compansata  for  tha  failura  during  a  mission 
(oiroult  Is  fault  tolarant),  but  It  will  ba  naoassary  to  Idantify  tha  condition  forfutura 
rapalr.  Tha  simpiast  solution  Is  to  usa  a  binary  countar  to  racord  tha  numbar  of 
falluras.  Tha  count  of  falluras  datactad  dividad  by  tima  will  giva  a  failura  datactlon 
rata.  A  failura  datactlon  rata  thrashold  can  ba  usad  to  Idantify  tha  axistanoa  of 
systam  faults. 

Another  method  of  compensating  for  "soft**  falluras  In  data  transmission 
and  data  storage  retrieval  circuitry  Is  to  usa  checksums,  parity  codas,  or  residua 
codas  to  Idantify  falluras  and  than  to  retry  tha  operation  encompassing  tha  failura. 
These  approaches  ware  discussed  In  earlier  sections.  These  methods  will  not 
provide  tolerance  for  "hard”  (permanent)  falluras  and  will  result  In  performance 
degradation  for  "soft"  falluras.  Thus,  they  provide  only  a  limited  form  of  fault 
tolerance. 

4.S.2.2  U**  of  the  TM  ttua  with  Pault-Tolarant  CIroulta 

A  part  of  each  fault*tolarant  oiroult  is  a  oiroult  which  racognlzas  that  thsra 
is  a  fault  and  provides  a  signal  which  Is  usad  to  taka  oorraotiva  action.  Because  tha 
purpose  of  fault  toiaranca  Is  to  permit  continuation  of  a  mission  In  tha  prasanoa  of  a 
fault,  It  Is  not  orltloal,  or  even  of  high  priority,  that  tha  failure  ba  made  known 
Immediately.  It  is,  however,  naoassary  that  tha  fact  ba  recorded  so  that  tha  faulty 
Item  can  ba  replaced  or  repaired  for  tha  next  mission.  Tha  TM  bus  la  an  axoallsnt 
method  to  meat  this  need. 

Figure  29  provides  an  example  of  how  these  circuits  would  fit  together. 
This  diagram  shows  two  redundant  microprocessors  monitored  by  a  watchdog 
circuit  and  tha  usa  of  ECC  for  both  memory  and  external  data  transmission.  Thus, 
there  are  three  elements  of  redundancy  and  fault  tolerance.  These  elements  of  fault 
tolerance  are  monitored  and  the  results  stored  In  the  TM  bus  controller  circuitry  for 
transmission  to  on-line  or  off-line  test  equipment  at  the  convenienos  of  that 
equipment. 

The  test  Information  maintained  In  the  TM  BUS  CONTROL  circuitry  need 
not  be  single  bits  of  data.  For  example,  the  watchdog  timer  could  time-stamp  a 
failure  event,  and  separate  counts  could  be  generated  of  errors  oorrectabls  by  the 
ECC  circuitry  and  errors  which  were  unoorrectabis  by  the  ECC  circuitry  for  both  the 
memory  and  the  communications  channel.  The  TM  bus  could  then  accept 
commands  for  transmitting  each  piece  of  data  as  requested  to  the  testing  circuitry. 

4.0.2  Applicability  to  Design  Levels 

Most  of  the  concurrent  techniques  discussed  are  appropriate  at  various 
levels  from  the  board/module  upward.  This  Is  certainly  true  of  parity,  residue  codes 
and  the  watchdog  timer.  Pin  electronics  is  also  appropriate  for  use  with  both  analog 
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FIGURE  29.  CXAMPU  OF  TM  lUS  WITH  FAUIT-TOUERANT 
MICROPROCESSOR  SYSTEM 


•nd/or  digital  oireultry  at  all  luoh  lavala.  Fault*tolarant  dailgn  la  an  amarging 
taohniqua  with  applicability  at  all  lavala  from  tha  Individual  oomponant  to  an  antira 
ayatam. 

6.0  FAULMSOLATION  TECHNIQUI8 

Early  In  tha  Conoaptual  Phaaa  of  tha  aoquialtlon  prooaaa  of  a  waapon 
ayatam,  a  maintananoa  oonoapt  la  formulatad  that  will  auatain  tha  oparatlonal 
availability  raquiramanta.  Thia  maintananoa  ooneapt  raquiraa  a  apaolfloally  targatad 
daaign  affort  that  will  advanoa  thoaa  diagnoatio  alamanta  that  ora  outllnad  In  Tabla  1 
-  Diagnoatio  Support  Aotivltlaa.  Within  tha  raalm  of  fault  laolatlon  to  a  oiroult 
oomponant  or  aat  of  oomponanta  tha  taak  at  hand  la  to  gain  vlalblllty  Into  particular 
atata(a)  axlatlng  at  aoma  pradatarmlnad  point  or  noda.  Tha  phyaloal  packaging  of 
tha  oiroult,  tha  typa  oiroult  and  tha  maintananoa  phlloaophy  will  Impact  tha 
taohnlquaa  aalaotad  to  gain  thIa  vlalblllty.  Tha  following  paragrapha  provide  an 
overview  of  aavaral  taohnlquaa  that  may  be  employed.  All  tha  tachniquai 
addraaaad  depend,  to  aoma  extant,  on  tha  ability  to  force  tha  oiroult  Into  a  apaclflc 
atata  and  than  provide  a  teat  aaquanoa  of  atimulua  and  anticipated  rasponaa.  This 
prooaaa,  called  Initialization,  muat  be  daaignad  Into  tha  oireultry  to  be  examined. 
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5.1  Ttst  Points 

Ths  discussion  of  test  points  will  focus  on  the  Incorporation  of  these  points 
for  the  Injection  of  system  stimulus  and  the  performing  of  associated  measurement 
to  validate  ;he  effect  on  the  circuit  of  that  stimulus,  or  to  verify  that  the  circuit  Is  In  a 
specific  quiescent  state. 

The  placement  of  measurement  test  points  on  a  module  provides 
Information  ^^bout  the  Internal  status  of  that  module.  This  Information  Is  used  by 
either  on>line  or  off<line  external  test  equipment.  It  Is  particularly  useful  for  fault 
Isolation  In  situations  where  there  may  otherwise  be  no  way  of  determining  which 
component  caused  the  failure.  Placement  of  measurement  test  points  may  also  be 
a  part  of  the  test  strategy  which  is  used  to  screen  modules.  This  strategy  Is  based 
on  partitioning.  '1110  circuit  Is  broken  Into  separately  tested  partitions  by  stimulus  test 
points  and  the  results  road  out  of  the  measurement  test  points. 

The  key  Issues  associated  with  measurement  test  points  are  how  to  place 
them  to  obtain  the  optimum  amount  of  Information  and  how  to  protect  the  circuit 
from  loads  and  capacitances  added  by  the  test  points.  These  Issues  become 
particularly  critical  when  there  Is  both  a  limited  number  of  edge  connectors  which 
can  be  used  for  test  points  and  when  the  board  area  or  weight  restrictions  limit  the 
amount  of  circuitry  which  can  be  used  to  muHIpiex  test  points  to  the  edge  connector. 
The  following  principles  have  been  found  to  best  address  these  key  Issues. 

Whenever  possible,  place  a  test  point  at  the  output  of  each  replaceable 
Item.  When  this  cannot  be  done,  it  may  not  be  possible  to  fault  Isolate  to  one 
replacetble  component  because  an  observed  failure  can  be  caused  by  either  of  two 
components.  A  simple  case  where  this  Is  true  Is  shown  In  Rgure  30. 

Providing  visibility  through  this  approach  is  particularly  Important  when 
several  packages  make  up  a  shift  register,  comparator,  or  parity  generator/checker. 
The  proper  placement  of  test  points  for  these  cases  are  shown  in  Figure  31. 
Another  case  where  test  points  may  be  particularly  necessary  for  fault  isolation  are 
embedded  RAMs  and  ROMs.  The  placement  of  test  points  In  these  cases  Is  shown 
in  Figure  32. 
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TP2  TP1 


TP2  TP1 


TP2  TP1 


TPn  TPm  TPo 

A  FAILURE  CAN  8C  ISOUTEO  TO  FAILED  ITEM  DIRECTLY 
TP2  TP1  TP2 


A  FAILURE  DETECTED  AT  TP2  OF  REPLACEABLE  ITEM  3  CAUSES 
AN  ISOLATION  AMBIQUITY  SHWEEN  REPLACEABLE  ITEM  2  AND  3 

FIGURE  30.  IMPACT  OF  TEST  POINTS  LIMITED  TO  CERTAIN  OUTPUTS 
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RGURE  31.  EXAMPLES  OF  APPROACHES  TO  ACHIEVE  TESTABILITY  IN  MULT1PACKA0E 
SHIFT-REGISTER.  COMPARITOR.  PARITY  GENERATOR/CHECKER  CHAINS 
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Place  test  points  so  as  to  meet  fault  Isolation  ambiguity  group  size 
requirements.  If  the  ambiguity  group  size  la  three  components  or  less,  then  test 
points  should  be  placed  at  least  between  every  third  replaceable  component  of  a 
sequential  circuit.  An  example  of  this  type  of  placement  Is  shown  In  Rgure  33.  The 
fault-isolation  ambiguity  group  size  requirement  places  a  minimum  test  point  count 
burden  on  the  circuit  designer. 

Place  test  points  on  the  controlled  side  of  LED  or  lamp  display  circuits. 
Placing  test  points  on  the  uncontrolled  side  of  an  LED  or  lamp  provides  no 
information  because  It  Is  tied  directly  to  VCC  or  ground.  The  use  of  this  principle  In 
the  selection  of  the  proper  place  to  Insert  a  test  point  Is  demonatrated  In  Figure  34. 
As  part  of  this  demonstration,  Figure  34  also  shows  that  a  test  point,  TP1 ,  on  the 
base  of  a  transistor,  driven  by  a  load  to  VCC,  provides  little  additional  Information 
and  should  be  removed.  That  particular  test  point  can  not  be  used  to  determine 
whether  the  transistor  Is  operative  or  not  because  Its  value  normally  reflects  whether 
the  transistor  Is  on  or  off.  For  the  same  reason,  that  test  point  would  not  show 
whether  the  Inputs  on  the  other  side  of  the  capacitor  were  faulty  or  not  unless  the 
capacitor  itself  failed  •  an  unlikely  event. 


nOURC  33.  LOGIC  TEST  POINTS  FOR  MULTIPACKAOC  SEQUENTIAL  CIRCUITS 


NON-PREFERRED  METHOD  PREFERRED  METHOD 


TP3  COULD  BE  USED  TO 
DETERMINE  THE  LAMPS 
STATUS  at  OPERABILTTY 
OF  THE  TRANSISTOR 

CAPACrrOR/RESISTUR  HAS 
LOW  PROBABILTIY  OF 
FAILURE  WHEN  COMPARED 
WITH  TRANSISTOR 

FIGURE  34.  OPTIMUM  TEST  POINT  SELECTION  FOR  LAMP  OR  LED  CIRCUITS 
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Provid*  t«8t  points  to  show  ths  status  of  rodundant  circuits.  Radundant 
circuits  provide  a  particular  problem  for  fault  Isolation  since  a  failure  In  them  may  not 
result  In  degraded  or  modified  performance.  This  characteristic  makes  them 
attractive  for  Increasing  the  system  or  subsystem  reliability.  Such  an  improvement, 
however,  Is  lost  If  the  failure  of  the  redundant  part  Is  not  observed  and  corrected. 
Figure  35  shows  an  example  of  how  test  points  could  sen/e  this  purpose. 

Where  signals  may  be  sensitive  to  load  or  noise.  Isolate  the  test  point 
from  the  external  edge  connector.  Test  points  should  not  modify  ths  performance  of 
the  circuits  to  which  they  are  attached.  To  assure  this,  heavily  loaded  or  sensitive 
circuits  should  be  isolated  from  the  test  point  by  resistors  or  buffers.  Examples  of 
these  types  of  circuKs  appear  in  Figures  36  and  37. 

Where  one-shots  must  be  used,  provide  test  points  at  their  output.  The 
timing  of  one-shots  Is  determined  by  analog  components  which  do  not  have  the 
accuracy  of  synchronous  digital  circuitry.  Such  circuitry  is  usually  driven  by  crystal- 
controlled  clocks.  In  addition,  one-shot  timing  Is  fixed  and  cannot  be  altered  under 
the  control  of  an  external  test  signal  as  It  has  only  one  stable  state,  rather  than  two. 
This  creates  a  variety  of  problems  in  testing  loglo  circuitry  that  contains  one-shots. 
The  larger  the  number  of  one-shots,  the  more  difficult  the  test  problem.  Therefore, 
one-shots  should  be  avoided  wherever  possible,  if  they  are  used,  test  points  should 
be  provided  at  their  outputs  to  allow  monitoring  of  the  output  pulse  duration  so  that 
It  can  be  tested  for  minimum  and  maximum  duration. 

Stimulus  test  points  are  primarily  used  to  Isolate  circuit  partitions  from 
each  other  for  test  purposes,  to  break  feed  back  loops,  and  to  select  test  data  to  be 
observable  at  edge  points.  In  effect,  they  are  used  to  reconfigure  Inherently 
untestsble  circuit  elements  into  forms  which  can' be  tested.  Thus,  they  are  often  the 
key  technique  used  In  making  a  circuit  testable. 

As  with  measurement  test  points,  there  frequently  are  limitations  Imposed 
on  the  number  of  stimulus  test  points.  Such  limitations  are  Imposed  by  the  limited 
number  of  edge  connector  pins  available  and  system  requirements  which  restrict  the 
total  board  area  or  weight.  Thus  the  key  stimulus  test  point  Issues  are  how  to 
provide  the  optimum  circuit  testability  with  a  limited  number  of  test  points  and  how  to 
do  It  In  a  way  which  does  not  Impact  circuit  performance.  The  following  paragraph 
addresses  the  key  Issues; 
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OKviotoumns 

FIGURE  36,  TEST  POINTS  FOR  TRIPLE  MODULAR  REDUNDANT  CIRCUITS 


COMMON  EMITTER  AMPUFIER  WITH  UNBYPASSED  EMITTER  RESISTOR 


FIGURE  36.  ISOLATING  THE  CIRCUIT  FROM  A  TESTPOINT  WITH  A  RESISTOR 
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nOURE  37.  ISOUTINO  THE  CIRCUfT  FROM  A  TESTPOINT  WrTH  A  BUFFER 


Ut«  ftimului  t«ft  points  to  isolsto  fr«o>runnlng  osolllstors  from  othtr 
oiroults.  CIroults  which  cannot  ba  dltconnaotad  from  froa>runnlng  oscillators  aro 
almost  always  difficult  to  tast  with  off-iina  ATE.  This  can  ba  causad  by  savaral 
factors,  Including: 

0  Tha  tast  rata  raquirad  to  synchronize  tha  ATE  with  tha  oscillator  may 
ba  highar  than  tha  ATE  capability. 

0  Tha  baginning  of  a  tast  saquanca  may  not  ba  synohronizabla  with  a 
known  circuit  stata. 

0  Tha  ATE  may  raquira  an  indatarmlnata  amount  of  sat-up  tima  batwean 
sagmants  of  a  tost  saquanca  with  tha  raoult  that  tha  circuit  stata  at  tha 
start  of  tha  naxt  sagmant  cannot  ba  datarmlnad. 
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For  all  thoaa  raaaons,  it  is  Important  to  disconnect  the  free-running 
osciiiator  from  the  remaining  circuits  and  to  provide  a  method  of  controiling  the 
actual  clock  signals  with  stimulus  test  points.  Figures  38  through  41  show 
techniques  for  accomplishing  this  task. 

Provide  stimulus  test  points  to  force  input  values  which  would  otherwise 
require  many  atepa  to  aet.  Eapeclaily  with  counter  clrcuita,  test  program  execution 
may  become  Inordinately  long  If  the  entire  circuit  chain  can  only  be  stimulated  from 
one  end.  In  these  oases,  as  Illustrated  In  Figure  42,  Internal  points  should  be  made 
acoessible  at  locations  which  the  performance  of  the  Individual  packages  (ICs)  may 
be  both  monitored  and  have  test  stimuli  injected.  As  an  example,  a  3-stage  12-blt 
counter  chain  would  take  4,006  steps  to  test  from  one  end,  whereas  only  16  steps 
are  required  for  teat  If  the  Inputs  and  outputs  of  the  Individual  packages  are 
accessible. 

Provide  stimulus  teat  points  to  open  feed-back  loops.  Feed-back  loops  In 
logic  olroultry  present  two  testability  problems.  First,  they  make  It  more  difficult  to 
generate  the  teat  patterns  because  the  feed-back  modifies  the  effect  of  the  Injected 
test  patterns.  Secondly,  they  Increase  the  size  of  the  fauN-lsolatlon  ambiguity  group 
because  any  fault  In  the  loop  propagates  to  ail  points  In  the  loop,  The  solution  to 
the  feed-back  problem  Is  to  break  the  feed-back  loop  either  through  jumper  wires  on 
the  board  edge  or  by  the  Insertion  of  additional  logic,  components  which  allow  one  to 
block  the  feed-back  and  possibly  also  to  inject  additional  teat  signals.  Examples  of 
these  techniques  are  shown  In  Rgures  43  through  47. 

The  additional  2-Input  AND  gate  inserted  In  the  circuit  of  Figure  43  allows 
one  to  block  the  feed-back  by  placing  a  logic  low  on  the  testpoint,  thereby  producing 
a  logic  low  at  the  Input  to  the  left-hand  logic  block. 

In  Figure  44,  the  use  of  an  external  jumper  to  break  the  feed-back  path  Is 
shown  aa  one  solution  which,  however,  may  not  be  usable  at  high  frequencies 
because  of  the  added  path  length.  It  requires  two  connector  points.  An  alternate 
approach  which  allows  one  to  put  a  logic  high  on  one  of  the  Inputs  to  the  right-hand 
AND  gate  Is  shown  In  the  lower  portion  of  Figure  44.  Plaoing  a  logic  low  on  the 
Input  of  the  inverter  will  disable  the  feed-back  path  and  allow  input  C  to  reach  the  D- 
type  flip-flop.  Figures  46  and  46  show  similar  examples  of  the  use  of  additional  logic 
to  control  the  feed-back  path. 

Sometimes  the  feed-back  is  not  implemented  by  a  single  logic  line  but  by 
(potentially  a  large  number  of)  parallel  lines.  In  this  case,  as  Illustrated  In  Rgure  47, 
a  multiplexer  can  be  used  effectively  to  disable  the  feed-back  path  and  allow  the 
Injection  of  test  signals  via  pins  2, 3, 4,  and  5  of  the  multiplexer. 
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AVOID  THIS  USE  THIS 


ALLOW  Aa  FREC-RUNNiNO  CLOCKS  TO  II  MIAILID  PROM  CONNECTOR 
AND  THE  TESTER  CLOCK  TO  SE  INSERTED  IN  RIAOI  OP  THE  PRIt>«RUNNINO 
CLOCK. 


FIGURE  38.  CIRCUIT  DESIGN  APPROACH  TO  ISOLATE 
FREE-RUNNING  OSCtUATORS 


FOR  OSCtUATORS  <  2  MHl.  TME  OSOLUTOR  VONAL 
CAN  IE  SROUOHT  OPP  THE  SOARO  ANO  SACK  VIA 
TWO  CONNECTOR  PINS  AM)  A  JUMPER  IN  THE 
lACKPLANI  TO  COMPUTE  TNI  CtRCUfT 
IN  THE  SYSTEM. 


FOR  OSetlUTORS  >  2  MHi.  INSERT  TWO  NANO  OATES 
(A  AND  I)  INTO  THE  OSCILLATOR  PATH.  PLACE  PUUJUP 
RESISTORS  WITH  Tir  POINTS  ATTAOHPO  ON  UNI  OP 
THE  TWO  INPUTS  ON  OATES  AM.  A  LOW  LEVEL  ON 
TEST  POINT  1  INMOm  THE  OSOIIATOR.  THE  COUNTER 
CAN  DC  CHECKED  INDIPCNOINT  OP  THE  OSOLLATOR 
VIA  TEST  INPUT  Z 


FIOURC  30.  TECHNIQUES  POR  ISOUTINO  PREE-RUNNINO  OSCILLATOR 
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FOR  OSOUATOR  >  2  MHi 
INSERT  ONE  OREN->CO(XBOTOR  NANO  OATI  (A) 
INTO  THE  OSOUATOR  RATH.  RUT  A  RUUUR 
RESISTOR  WITH  A  TEST  ROKT  ON  ONE  INRUT. 
RUUUR  THE  OUTRUT  AND  RUT  TEST  ROINT  2 
ON  THE  OUTRUT.  A  lAW  LEVEL  ON  TEST  ROINT 
INHlSrrS  THE  OSOUATOR  AND  AUOWS  CLOCKS 
TO  IE  RROVIOCO  VIA  TEST  RONT  X 


OPEN-COUEOTOR  NANO 
.2 


BT  BRINOINO  THE  TERMINAL  COUMTB  Off  THE  iOAROiMINOINO  ANOT^  t^lN  OWO  THB 
A3  AN  INPUT  TO  THE  CET  CONTROL  UNES.  THE  COUNTER  STRING  IS  BROKEN.  IHnE  PINS  CAN 
BE  BACKPLANE-JUMPERED  IN  THE  ffrSTEM  TO  COMPLETE  THE  STRINO. 


ADO  "OR"  OATES  A  AND  B  BCTV/EEN  THE  TERMINAL  COUNTS  AND  Cr  INPUTS  OP  TRE  COUNTERS. 


BRING  THE  OTHER  INPUT  OFT  THE  BOARD  WK  UNUBED  PIN  OR  TWT  POINT.  BT  PUITINO  A  "ni" 
ON  PINS  1  AND  2.  YOU  ENABLE  COUNTERS  II  AND  III  TO  COUNT  AT  THE  SAME  TIME  COUNTER  1 
DOES.  THIS  REDUCES  THE  NUMBER  OP  CLOCKS  RKOUWCD  TO  TEST  THE  ONCUIT  PROM  40BS  TO  IS. 


RQURE  42.  EXAMPLES  OF  BREAKINQ  UP  COUNTER  STRINGS. 


FIGURE  43.  EXAMPLE  OF  INSERTION  OF  AOOmONAL  LOGIC  COMPONENT 
TO  CONTROL  FEED-iACK  PATH 
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FIGURE  45.  ADDITIONAL  EXAMPLE  OF  USING  LOGIC  COMPONENTS 
TO  PROVIDE  FEED-BACK  CONTROL 
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Th«  following  list  Is  axoerpted  from  MIL-STD-2165  and  Is  Intandad  to 
summariza  UUT  fast  point  salaotlon.  Tha  numbar  and  placamant  of  such  tast  points 
is  basad  upon  tha  following: 

0  last  points  ara  salaotad  basad  upon  fault*isolatlon  raqulramants. 

0  Tost  points  salaotad  ara  raadlly  aooassibla  for  oonnaotlon  to  ATE  via 
systam/aquipmant  oonnaotors  or  tast  connactors. 

0  Tast  points  ara  ohoaan  so  that  high  voltaga  and  ourrant  maasuramants 
ara  oonsistant  with  aafaty  raqulramants. 

0  Tast  point  maasuramants  lalata  to  a  common  aquipmant  ground. 

0  Tast  points  ara  daoouplad  from  tha  ATE  to  assura  that  dagradatlon  of 
aquipmant  parformanoa  doaa  not  occur  as  a  rasuK  of  oonnaotors  to  tha 
ATE. 

0  Taat  points  of  high  voltaga  or  ourrant  ara  physloally  liolatad  frpm  tast 
points  of  low  logic  lavat  signals. 

0  Tast  points  ara  salaotad  with  dua  oonsldaratlon  for  ATE 
Implamantatlon  and  oonsistant  with  raasonabla  ATE  fraquanoy 
raqulramants. 

0  Tsai  points  ara  ohoaan  to  aagragata  analog  and  digital  oiroultry  for 
Indapandant  tasting. 

0  Taat  points  ara  salaotad  with  dua  oonsldaratlon  for  ATE 
implamantatlon  and  oonsistant  with  raasonabla  ATE  maasuramant 
aoouraolas. 

Aooaptonoa  tasting  for  moduias  shall  normally  ba  parformad  using  only 
tha  modula  I/O  oonnaotor,  and  shall  not  dapand  on  tasting  parformad  praviously  to 
aasura  tha  modula  masts  Its  functional  and  parametric  raqulramants.  Howavar, 
axoaptlona  to  this  requiramant  may  ba  granted  on  a  oasa-by-casa  basis,  as  follows: 

Tast  points  may  ba  used  for  acoaptanca  tasting  on  vary  oomplax  digital 
moduias  where  the  controllability  and  observability  of  LSI  or  VLSI  circuits  cannot 
otherwise  ba  achieved  to  tha  degree  naoaasary  to  mast  tha  Intarnel  gata<laval 
coverage  requiramant  (usually  99  percent).  Tast  points  may  ba  used  for  acoaptanca 
tasting  on  oomplax  analog  moduias  where  naoaasary  to  test  all  critical  circuit 
operations. 
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5.2  T«at  HMCtor 

The  test  header  incorporated  in  a  UUT  generally  consists  of  a 
maintenance-use-only  connector  which  provides  the  necessary  access  to  test  points 
In  the  off-line  test  mode.  In  all  modules,  the  number  of  input  and  output  lines  which 
can  be  dedicated  to  measurement  and  stimulus  test  points  is  limited.  This  limitation 
can  be  somewhat  overcome  by  using  one  Input-output  line  for  several  test  points 
and  bringing  the  line  out  through  the  test  header.  There  are  seven  types  of 
techniques  for  combining  the  test  point  access: 

0  Multiplex  the  measurement  test  points 

0  Convert  several  test  point  values  Into  serial  data  (parallel-to-serial 
conversion) 

0  Compress  data  taken  over  several  clock  steps  Into  a  signature 
(signature  analysis) 

0  Decode  or  demultiplex  test  point  stimulus  signals 

0  Convert  aerial  Input  data  to  values  on  several  test  points  (serlal-to- 
parallel  conversion) 

0  Use  an  LSSD  or  equivalent  method 

o  Use  a  digital  testability  bus. 

Most  of  these  design  approaches  can  only  be  applied  to  digital  circuits 
and  require  MSI  or  larger  packages.  One  or  more  of  these  techniques  should  be 
used,  independently  or  In  combination,  In  the  circuit  design  of  each  module. 

Test  header  use  Is  confined  to  assisting  In  off-line  testing.  The  header  is 
not  to  be  'ised  In  any  other  application.  Any  continuous  monitoring  Is  accomplished 
through  the  use  of  Input  and  output  pins.  Many  modules  will  be  relatively  easy  to 
test  and  fault  isolate,  while  others  may  be  quite  difficult.  Therefore,  test  header 
usage  rules  should  vary  depending  upon  the  needs  of  the  individual  module.  The 
following  test  header  usage  shall  apply  to  each  module,  when  test  connector  usage 
Is  allowed,  and  are  listed  in  order  of  descending  preference; 

0  Only  outputs  shall  be  brought  to  the  test  connector  to  enhance 
observability.  No  driving  of  inputs  nor  overdriving  of  outputs  shall  be 
performed. 
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0  Only  outputs  and  Inputs  which  do  not  require  critical  timing,  or  are  not 
affected  by  parasitics  (such  as  trI-state  controls)  shall  be  brought  to  the 
test  connector.  No  overdriving  of  active  outputs  shall  be  performed. 

0  Overdriving  of  active  outputs  may  be  performed  only  as  a  last  resort 
on  the  most  complex  modules,  with  a  test  afterwards  to  verify  that  the 
module  was  not  damaged. 

0  Physical  breaking  of  signals  through  the  test  connector  shall  not  be 
allowed  under  any  circumstances. 

Use  of  the  test  header  is  allowed  for  all  QO/NOQO  and  fault-isolation 
testing  In  the  authorized  maintenance  environment  without  restriction.  However, 
proper  caution  should  always  be  exercised  so  that  the  test  equipment  utilized  does 
not  present  to  the  header  pins  an  excessive  amount  of  resistive  or  capacitive 
loading.  Resistive  values  less  than  100  K  ohms  and  capacitance  values  In  excess 
of  50  picofarads  are  deemed  excessive. 

5.3  Inoreaaing  I/O  Vlalblllty 

The  structured  techniques  discussed  earlier  (e.g.,  scan  design)  Inherently 
Improve  the  test  visibility  of  the  circuitry  in  question,  Less  structured  techniques  are 
also  available  for  SSI,  MSI  level  designs.  Figure  48  shows  a  shift  register  used  to 
capture  a  test  vector  from  multiple  critical  circuit  nodes  on  a  PC  board.  The  number 
of  nodes  could  be  6, 16,  32  or  more  depending  on  the  shift  register  used.  The  test 
vector  is  then  shifted  serially  off  the  board.  Thus,  with  only  a  small  number  of  I/O 
pins  (i.e.,  shift  clock,  output,  etc.)  a  large  test  vector  readout  can  be  achieved.  Since 
the  shift  register  presents  a  high  input  resistance  to  the  nodes  and  drives  off  the 
board  via  a  low  output  resistance,  the  electrical  situation  is  optimal.  The  system 
penalty  Is  that  board  real  estate  must  be  used  to  accommodate  the  shift  register 
chip. 


Figure  49  depicts  an  alternate  approach.  Here  a  multiplexer  is  used  to 
capture  critical  circuit  nodes.  By  controlling  the  multiplexer  address  via  MUX  select 
lines  on  the  PC  board  edge  connector,  a  single  node  at  a  time  can  be  selected  and 
read  out.  The  result  is  the  same  as  with  the  shift  register,  many  nodes  can  be 
accessed  with  a  small  penalty  in  I/O  edge  pins.  Here  too  the  electrical  situation  Is 
optimal  and  the  penalty  to  achieve  increased  visibility  similar  to  the  shift  register 
case.  Which  approach  Is  selected  will  probably  depend  on  the  test  philosophy.  Is 
the  data  usually  read  out  on  all  nodes  during  a  test  cycle  or  Is  less  than  a  total  read 
more  likely?  The  shift  register  is  probably  preferable  In  the  former  case  and  the 
MUX  In  the  latter. 
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LOAD 

VECTOR 

SHIFT 

OinPlTT 


•  CAPTURES  ENTIRE  VECTOR 


ROURC  4«.  IMPROVING  OBSERVABILITY  WITH  UMITCD  I/O  PINS 
(SHIFT  RCOISTCRS) 


•  SELECT  ONE  NODE  AT  A  TIME 


FIGURE  49.  IMPROVING  OBSERVABILITY  WITH  UMITED  I/O  PINS  (MUX) 
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5.4  Fault  SIgnatura/Fault  Dictionary 

Tha  Fault  SIgnatura/Fault  Dictionary  taehnique  somatimas  providas  an 
axcallant  mathod  for  fault  isolation  of  a  logic  fault  within  a  complex  digital  davica. 
Tha  application  of  selected  teat  patterns  to  the  Input  and  a  comparison  of  the  output 
values  to  the  predetermined  expected  value  for  a  fault-free  circuit  can  Identify  a 
failed  component  provided  the  fault  signature  Is  lodged  In  the  program  dictionary.  In 
some  cases  the  fault  may  be  unlisted  or  isolated  to  a  group  of  components  and 
require  additional  application  of  the  guided  probe  technique  to  resolve  the 
discrepancy  (Refer  to  Section  5.5). 

In  order  to  establish  a  fault  dictionary  for  a  particular  circuit  card,  a  logic 
simulation  run  Is  conducted.  An  Inventory  of  selected  faults  Is  established  and  the 
test  steps  where  failures  are  first  detected  are  recorded  along  with  Input/output 
pin  states.  The  pin  states  that  differ  from  those  of  a  known-good  circuit  are  stored  In. 
a  dictionary  file.  Actual  failures  cause  the  test  system  to  search  the  dictionary  for  a 
match  at  the  failed  test  step  and  matching  failed  output  pins.  Since  the  actual  failure 
mode  possibilities  are  usually  too  numerous  to  be  simulated,  the  possibility  bxlsts 
that  a  fault  will  occur  for  which  there  Is  no  dictionary  match.  If  an  unlisted  fault  does 
occur,  the  fault  will  be  detected  but  may  be  misdiagnosed,  Actually  three 
possibilities  exist:  corrsot  diagnosis.  Incorrect  diagnosis,  and  no  match, 

The  problems  associated  with  the  standard  fault  dictionary  technique,  as 
described  above,  can  be  reduced  through  the  use  of  dynamic  dictionary  look-up 
fault-isolation  methods.  These  methods  are  Implemented  by  reorganizing  tha 
dictionary  structure,  processing  the  dictionary  In  real  time  and  appiying  the  specific 
algorithms. 


5.5  Quided  Probe/Cllp 

Probably  the  most  common  fault-isolation  technique  In  use  Is  the  guided 
probe  or  multi-contact  clip  that  Is  applied  manually  to  the  point  under  Investigation. 
Accessibility  to  the  point  to  be  tested  can  sometimes  be  denied  due  to  circuit  layout, 
modern  packaging  techniques  or  the  application  of  conformal  coatings.  These 
restrictions  are  overcome  by  the  careful  selection  of  the  best  available  test  point, 
addition  of  test  points  (see  Para.5.1)  and  penetration  of  the  conformal  coating. 

The  overall  effectiveness  of  the  guided  probe/clip  depends  upon  the 
circuit  testability  characteristics,  the  depth  of  the  software  used  to  direct  the  operator 
to  the  proper  test  point,  and  the  system  program  to  manipulate  the  data  from  the 
probe  to  yield  accurate  fault  Isolation.  One  significant  disadvantage  of  the  guided 
probe  Is  the  slowness  inherent  In  physically  moving  the  probe  numerous  times, 
However,  the  technique  most  often  does  result  In  the  eventual  Identification  of  the 
faulty  component.  Combinations  of  fault  signature/fault  dictionary  and  guided 
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probe/clip  can  often  speed  up  the  process  via  the  computer-based  attributes  of  the 
former  technique  while  still  maintaining  the  accurate  isolation  properties  of  the  latter. 

Node  access  is  needed  to  fault  isolate  PCBs  by  the  guided  probe 
technique.  To  achieve  nodal  access  (measurement  and  stimulus  test  points),  design 
consideration  and  real  estate  must  be  provided  at  the  early  design  stages. 

Providing  individual  probe  access  to  each  device  pin  could  require  20-25 
percent  of  the  total  PCB  space  and  would  be  a  considerable  trade-off  consideration 
In  the  decision  of  whether  to  use  SMD  for  a  design.  Fortunately,  a  typical  digital 
logical  design  may  have  3  to  4  or  more  component  leads  per  node.  One  probe 
access  per  node  should  be  sufficient  for  maintenance  diagnostics  by  guided  probe. 

One  visibility  point  per  node  Is  not  enough  to  provide  for  Isolation  of  PCB 
trace  opens.  However,  this  failure  mechanism  is  not  common  for  fielded  PCBs  that 
have  not  been  mishandled.  Fault  Isolation  to  the  component  level,  Including  open 
Input  or  output  connections,  is  possible  with  one  contact  point  per  node. 

It  is  recommended  that  contact  points  be  no  closer  than  50  mil  centers. 
Leads  from  device  pads  to  test  pads  should  be  necked  down  to  a  maximum  of  one 
half  of  the  solder  pad  width  to  provide  for  thermal  isolation  during  the  soldering  snd 
de-soldering  processes.  Examples  of  probe  contact  pad  layout  are  shown  In  Figures 
50  and  51 . 

Physical  access  to  each  node  may  also  be  obtained  by  providing  test 
connectors  called  teat  headers.  The  test  header  provides  the  additional  advantage 
of  making  the  node  available  without  the  need  to  puncture  a  PCB's  conformal 
coating.  As  shown  In  Rgure  52,  the  PCB  area  penalty  to  provide  100  percent  access 
to  all  device  pins  might  be  as  much  as  one  third  of  the  total  PC  area.  However, 
complete  nodal  access  (typically  four  pins  per  node)  could  be  provided  using  one 
ninth  of  the  PCB  space. 

Since  the  guided  probe  is  the  predominant  fauH-isolatlon  technology  used 
at  the  Intermediate  and  Depot  maintenance  levels,  it  Is  very  desirable  to  provide  the 
ability  to  physically  probe  critical  nodes  as  described  In  Section  5.5.  If,  however,  a 
determination  Is  made  that  providing  for  physical  probe  points  would  prevent  a 
system  from  meeting  its  program  objectives  of  size  and  weight.  It  might  be 
necessary  to  rely  on  one  or  more  other  fault-isolation  or  nodal  access  techniques. 
The  following  techniques  could  be  used  without  nodal  access; 

No  Fault  Isolation 

In  some  circumstances,  such  as  when  the  PCB  reliability  is  very  high,  and  the 
manufacturing  cost  is  low,  It  may  be  desirable  to  scrap  rather  than  repair  defective 
PCBs. 
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COMPLETE  NODAL  ACCESS  CTYPICALLY  4  PINS/NODC) 
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Artificial  Intalllganca  (Al) 

Al  may  ba  used  In  combination  with  other  tachniquas  to  help  detarmlna  tha  moat 
likaly  causa  of  tha  fallura. 

On-ChIp  BIT 

LSI,  VHSIC,  and  custom  gata  array  davioas  may  hava  bullt<ln  salt  tast  capability.  A 
PCB  dasignad  axclualvaly  of  thasa  davicas  could  control  and  utilize  this  tast 
capability  to  report  device  fallura  Information.  If  direct  nodal  access  Is  not  possible, 
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and  the  techniques  above  do  not  provide  the  solutions,  electrical  nodel  access  can 
be  provided  by  multiplexing  or  scan  techniques. 

5.6  Use  of  TM  Bua 

The  incorporation  of  a  standard  testability  bus  in  the  system  architecture 
greatly  enhances  the  capability  to  fault  isolate  an  assembly  to  a  defective  module. 
The  description  of  this  concept  and  details  of  its  application  are  contained  In  Section 
7.0. 


6.0  PHYSICAL  PACKAGING 

Automatic  electronic  assembly  technology,  currently  in  use  by  most 
military  electronic  equipment  manufacturers,  is  forcing  a  definite  change  to  the 
physical  form  of  the  circuit  components.  The  trend  toward  ICs  with  high  pin  counts 
(above  48)  and  higher  frequency  requirements  is  also  dictating  a  move  away  from 
the  almost  standard  Dual  ln*llne  Package  (DIP)  and  formed  lead  components.  The 
advent  of  VLSI  technology  requires  new  and  more  dense  packaging  and  has 
accelerated  the  trend  away  from  conventional  PCB  layout  and  assembly. 

Numerous  new  component  forms  are  becoming  evident  as  technology 
and  manufacturing  techniques  advance.  There  is  a  strong  trend  toward  surface 
mounted  devices  (SMO)  which  provide  real  assembly  advantages  and  superior 
circuit  characteristics  at  higher  frequencies.  The  move  to  surface  mount  assembly  Is 
probably  the  most  Important  factor  that  will  determine  which  packages  are ’dominant 
In  the  Industry.  There  are  essentially  three  distinctive  new  styles  or  classes  of 
packaging  prominent  in  the  Industry  to  enhance  auto  assembly  and  dense 
packaging  strategies.  These  three  are  the  chip  carriers,  the  small-outllne  (SO),  and 
the  pin  grid  array  (PQA).  Of  these,  the  pin  grid  array  Is  a  through-board  mounted 
device. 


The  following  paragraphs  will  describe  the  newer  packages  and  address 
the  test  related  peculiaritios. 

6.1  Surface  Mounted  Devices 

A  surface  mounted  device  or  component  is  a  component  whose  electrical 
contact  to  the  PCB  Is  on  the  same  side  of  the  board  as  the  component  Itself.  These 
devices  do  not  require  a  hole  through  the  PCB.  The  tighter  packing  density  of 
surface  mount  compatible  packages  Is  allowing  systems  manufacturers  to  meet  the 
function  and  space  demands  by  reducing  PCB  real  estate  by  as  much  as  70 
percent.  Small  packages,  called  chip  carriers,  have  recently  been  developed  for 
high-density  packaging  applications.  The  benefits  of  surface  mounting,  which  Is  the 
method  required  for  chip  carriers.  Include  alleviation  of  many  of  the  constraints 
imposed  by  through-the-board  mounting  associated  with  DIPs.  For  example,  one- 
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sided  circuit  boards  using  surface  mounted  components  have  a  very  smooth 
underside  that  Is  well  suited  to  mounting  against  a  heat  sink  providing  even  and 
effective  temperature  stabilization.  Because  of  their  many  desirable  characteristics, 
chip  carriers  are  replacing  DIPs  at  all  pin  counts  and  the  Small-Outline  (SO) 
package  Is  becoming  popular  for  low  pin  count  use. 

Surface  mounted  packages,  like  chip  carriers  and  small  outline  packages, 
are  too  small  to  be  placed  by  hand  and  require  automated  assembly  techniques. 
Automated  assembly  techniques  have  the  added  advantage  of  providing  more 
consistent  quality,  higher  production  rates,  and  lower  unit  assembly  cost. 

6.2  Chip  Carriera 

The  surface  mounted  basic  chip  carrier,  as  shown  In  Figure  63,  is  not  a 
total  replacement  for  through-the-board  1C  packaging  due  to  Imposed  limitations  on 
total  pin  count.  For  units  with  over  68  pins  a  packaging  technique  called  pin  grid 
array  is  used. 

Chip  carriers  are  generally  available  in  four  vet  slons: 

o  Leadless  Ceramic  Chip  Carrier  (LCCC) 

0  Leaded  Ceramic  Chip  Carrier  (LDCC) 

o  Plastic  Chip  Carrier  (PLCC  or  PCC) 

0  Pin  Grid  Array  (PQA) 

The  term  *leadless"  indicates  that  the  package  has  a  leadless  footprint. 

The  LCCC  Is  primarily  a  ceramic  substrate  with  metallzed  conductors 
extending  from  the  die-attached  cavity  to  the  periphery  of  the  substrate,  down  the 
edges  and  slightly  around  the  underside.  Most  versions  have  a  die  cavity  and  use 
normal  cavity  sealing  practices.  One  of  the  most  common  constraints  to  the  LCCC  Is 
that  the  board/package  Interface  Is  rigid.  The  thermal  expansion  of  the  ceramic  is 
sometimes  sufficient  to  cause  the  package  dimensions  to  change  enough  to  break 
the  ceramic,  or  disrupt  the  electrical  connection  between  the  package  and  the 
board.  Careful  mechanical  matching  techniques  can  generally  alleviate  this  problem; 
however,  temperature  excursions  caused  by  system  start  up  or  high 
performance/hlgh  power  operation  will  aggravate  the  problem, 

The  LDCC  is  produced  in  the  same  general  form  as  the  LCCC  except  that 
Instead  of  the  conductors  being  turned  under  the  underside  of  the  board,  they  are 
brought  out  at  right  angles  to  the  edge  as  shown  In  Figure  54. 
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The  leads  of  the  LDCC  provide  the  mechanical  compliance  necessary  to 
permit  use  of  a  ceramic  chip  carrier  with  an  epoxy  circuit  board. 

The  plastic  chip  carrier  is  constructed  using  techniques  that  are  virtually 
Identical  to  the  plastic  DIP.  The  principal  difference  Is  the  positioning  of  the  leads 
which  are  turned  under  the  underside  to  form  the  "J"  lead  which  effectively  produces 
the  same  footprint  as  the  LCCC.  The  PLCC  Is  usually  categorized  as  leadless. 
Figure  55  provides  a  summary  illustration  of  JEDEC  chip  carriers. 

6.3  Small  Outline  (SO)  Packages 

The  second  new  class  of  package  currently  very  popular  for  use  where 
very  little  PCS  real  estate  Is  available  is  the  SO  package.  In  appearance  It  looks  like 
a  micro-mlnlature  DIP  with  leads  bent  down  and  out  from  the  body  for  surface 
mounting.  It  occupies  approximately  one  fourth  of  the  surface  area  of  the  DIP; 
however,  In  configurations  of  greater  than  20  leads  or  more,  It  occupies  greater 
space  than  the  PLCC. 

The  SO  Is  available  in  8*,  14-,  and  16-pln  versions  with  an  0.150  Inch 
width  and  in  20«,  24>,  and  28-pin  versions  with  an  0.30  Inch  width.  Figure  56 
Illustrates  an  SO  package. 


6.4  Pin  Qrld  Arrays 

The  third  new  class  of  packaging,  the  pin  grid  array.  Is  not  a  true  surface 
mount  device  although  It  Is  similar  In  outline  to  the  chip  carrier.  It  Is  a  through-the- 
board  mounting  device  capable  of  accommodating  a  large  number  of  pins.  Although 
there  are  numerous  mounting  problems,  It  does  provide  the  best  solution  for 
mounting  situations  requiring  more  than  124  leads.  It  Is  widely  used  In  large  main 
frame  computer  applications. 

The  PGA,  shown  In  Figure  57,  Is  normally  constructed  from  a  ceramic 
substrate  with  metallzed  conductors  from  the  1C  attachment  area  to  an  array  of  pins 
located  on  the  underside  of  the  package.  The  pins,  used  for  through-the-board 
mounting,  are  spaced  in  a  regular  rectangular  pattern  with  0.10  Inch  spacing  and 
0.10  Inch  pitch. 

The  dense  array  of  pins  creates  significant  board  layout  problems  and 
soldering  and  desoldering  problems  are  prevalent.  On  the  positive  side,  however, 
the  PGA  is  compatible  with  assembly  methods  used  for  DIPs.  Is  extremely  rugged, 
Is  highly  area  efficient,  and  can  dissipate  significant  amounts  of  power  (12  watts). 
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JDEC  DESIGNATION 

CHARACTERISTICS 
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There  is  a  surface  mour)ted  version  of  the  PQA  which  uses  a  pad  grid 
array  on  the  underside  of  the  carrier.  This  unit  does  have  the  thermal  expansion 
problems  of  the  LCCC  and  the  ir'spection  of  the  soldered  Joint  Is  Impossible. 

6.5  Packegeleea  Configurations 

A  fabrication  technology  wherein  the  1C  device  unpacKaged  Is  attached  to 
the  board  with  adhesive,  and  the  leads  from  the  die  are  bonded  directly  to  the  board 
traces,  is  called  chip-on'board  packaging.  This  process  In  inexpensive  applications 
Is  especially  useful  where  a  high  level  of  protection  Is  not  required. 

Tape  Automated  Bonding  (TAB)  is  another  assembly  technology  which  is 
becoming  a  significant  packaging  technology.  A  sandwich  of  conducting  material, 
usually  copper,  and  a  stable  dielectric  film,  such  as  a  poiymide,  Is  formed.  The  film  is 
accurately  removed  and  the  beams  etched  to  match  the  package  lead  frame  at  an 
end  and  the  1C  bonding  pads  on  the  other.  The  sandwich  Is  bonded  to  the  iC  and 
attached  to  the  lead  frame.  A  critical  advantage  of  this  process  for  VLSI  circuits  is 
the  beam  separation  maintenance  by  the  tape. 

In  the  late  1970s  military  systems  used  flat  packs  for  nearly  45  percent  of 
IC  requirements.  Today,  chip  carriers  are  the  normal  mode  In  nearly  all  new  military 
systems  design  especially  in  airborne  systems,  with  their  need  for  extreme 
miniaturization  and  excellent  thermal  transfer  characteristics.  The  next  generation  of 
avionics  systems  will  likely  use  chip  carriers  exclusively.  The  ieadiess  carrier  is  not 
expected  to  be  prevalent  due  to  the  mechanical  problems  associated  with  Its  lack  of 
compliance  to  absorb  stresses  Imposed  by  thermal  shock.  The  leaded  ceramic  chip 
carrier  Is  becoming  more  and  more  common  and  is- expected  to  displace  the 
leadless  version.  Military  systems  manufacturers  are  Increasingly  using  chip  carriers 
to  house  multl’chip  assemblies  built  in  captive  hybrid  facilities. 

The  trends  in  military  computers  are  similar  to  those  noted  above  but 
there  Is  more  Interest  In  plastic  packages.  The  leaded  carrier  la  being  accepted  here 
due  to  Its  good  thermal  conductivity  compliant  leads  and  hermetic  seals. 

6.6  Testing  Surface  Mounted  Devices 

With  the  increased  use  of  SMD  PCBs,  the  Intermediate  and  Depot  repair 
processes  will  change  to  adapt  to  this  new  technology.  Equipment  presently  being 
used  to  test  and  repair  conventional  PCBs  may  have  limited  or  no  capability  to 
handle  SMDs. 

Surface  mount  technology  causes  test  problems  and.  as  a  result,  test 
techniques  will  change  to  accommodate  these  problems.  The  predominant  fault- 
isolation  technique  at  the  Intermediate  shop  and  Depot  level  has  been  the  guided 
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probe.  Significant  testability  enhancements  must  be  made  to  SMD  PCBs  to  make 
effective  use  of  the  guided  probe  for  fault  Isolations  to  an  ambiguity  group  of  one  at 
the  component  level. 

For  many  SMD  packages,  the  actual  device  contact  surface  may  not  be 
accessible.  Additionally,  the  contacts  may  be  so  close  or  fragile  that  probing  could 
damage  the  component,  lead,  or  PCS.  One  increasingly  popuior  concept  is  to  mount 
the  base  1C  chip  directly  on  the  PCS,  either  using  wire  bonds,  or  a  reflow  solder 
technique  In  which  the  1C  chip  pads  directly  solder  to  the  PCS. 

Often  with  SMT  PCBs  an  individual  component  may  only  be  replaced 
once  before  the  PCB  may  be  scrapped.  This  is  caused  by  the  tact  that  smaller 
traces  and  pads  cannot  endure  as  much  heat  as  larger  pads  or  traces.  Also,  more 
heat  must  often  be  applied  to  remove  or  Install  en  SMD  since  all  device  connections 
may  have  to  be  heated  at  one  time.  This  requires  that  the  entire  repair  process  be 
considered  when  making  logistic  and  testability  trade-offs. 

7.0  TB8T  AND  MAINTBNANCE  BUS 

7.1  Overview 

The  TM  bus  has  been  discussed  in  various  preceding  paragraphs.  This 

section  provides  additional  detail  on  the  VHSIC  TM  bus  although  the  document 
entitled  "VHSIC  Phase  2  Interoperability  Standards,  TM  Bus  Spsolficrtion”  should 
bs  obtained  by  anyone  desiring  the  complete  and  official  VHSIC  TM  Bus 
Specification.  Also  discussed  in  this  section  are  other  TM  Bus  Initiatives  by  the 
JTAQ  and  IEEE  Committees. 

7.2  VHSIC  TM  BUS 

A  TM  bus  consists  of  a  set  of  signal  lines  that  provide  a  serial  path  for  tost 
and  maintenance  control  and  data  Information.  It  Is  a  linear,  multi-drop 
communications  media  which  transfers  bit  serial  data  between  s  "Master"  module 
and  a  number  of  slave  modules  residing  on  a  single  back  plane. 

Thise  contractors  -  Honeywell,  TRW,  and  IBM  -  through  their  VHSIC 
Phase  2  efforts,  have  generated  a  specification  for  a  standard  TM  bus  utilizing  only 
four  I/O  pins.  A  review  of  this  specification  supports  the  conclusion  that  it  provides 
an  excellent  standard  approach  accomplishing  all  benefits  cited  In  Section  3.5  with 
the  least  real  estate  penalties.  A  brief  description  of  this  bus  follows.  For  complete 
details,  refer  to  the  official  VHSIC  TM  Bus  Specification. 
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7.2.1  Physical  Rsquirsnwnts 

The  specification  provides  for  a  serial  path  consisting  of  four  lines 
between  the  master  and  slave  modules  with  capacity  for  paralleling  up  to  a  total  of 
32  slave  modules  Each  of  these  lines  is  dedicated  to  a  particular  bus  signal. 

These  signals  are: 

0  Clock 
0  Master  Data 
0  Slave  Data 
0  Control 

Figure  58,  TM  Bus  Signals,  depicts  the  general  master>8lave  module 
relationship  and  indicates  signal  flow.  The  bus  signal  characteristics  are  described 
in  the  following  paragraphs. 


FROM  CLOCK  SOURCE 


FIGURE  50.  TM  SIGNALS 
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7.2.2  ElMtrloal  Raqulramanta 

As  ststsd  praviously,  thsrs  are  four  signal  types  that  make  up  the  TM  bus. 

All  bus  signals  use  negative  logic.  I.e.,  the  logic  '1'  state  (or  asserted  state)  Is  the 
lowest  voltage  level  and  the  logic  'O'  state  (or  released  state)  Is  the  higher  voltage 
level  on  the  bus. 

The  TM  bus  CLOCK  signal  Is  a  single  phase  clock.  All  control  and  data 
transfer  operations  are  synchronized  with  the  TM  bus  CLOCK  signal.  All  data  and 
commands  are  placed  on  the  TM  bus  on  the  high  to  low  transition  of  the  clock  and 
latohed'In  on  the  next  high  to  low  transition.  The  CLOCK  signal  Is  typically  6.25 
MHz  and  single  phase.  Specific  voltage  levels,  rise  and  fall  time  and  duty  cycle  data 
are  contained  In  The  VHSIC  TM  Bus  Specification. 

The  TM  bus  MASTER  DATA  signal  Is  a  single  unNdlrectlonal  line  used  to 
transmit  device  addresses,  instruction  data,  and/or  scan  data  from  the  MASTER  to 
the  SLAVE(8).  The  MASTER  DATA  line  Is  also  used  in  conjunction  with  the 
CONTROL  line  to  Indicate  bus  states. 

The  TM  bus  SLAVE  DATA  signal  It  used  to  transmit  acknowledgements, 
data,  and/or  Interrupts  from  the  SLAVE(s)  to  the  MASTER.  The  TM  bus  SLAVE 
DATA  line  supports  a  wired  OR  configuration. 

The  TM  bus  CONTROL  signal  is  a  single  unl>dlreotlonal  line  from  the 
MASTER  to  the  SLAVE(8).  When  the  CONTROL  line  Is  asserted,  the  bus  Is  placed 
In  the  DATA  TRANSFER  state.  When  the  CONTROL  Is  released,  the  bus  Is  In  the 
PAUSE  or  IDLE  state. 

The  bus  signal  lines  hsve  a  characteristic  Impedance  of  between  20  snd 
60  ohms  and  are  terminated  In  the  Thevenin-equivalent  of  a  terminating  resistor  of 
30  •  40  ohms  In  series  with  a  voltage  source  of  between  -ft  .9  and  <*-2.1  volts. 
Speclflo  module  requirements  for  line  Input  capacitance  and  Inductance,  AC  and  DC 
voltage  ranges,  timing  relationships,  etc.  can  be  found  In  the  VHSIC  TM  Bus 
Specification, 

7.2.3  Data  Link  Requlremente 

The  TM  Bus  Is  the  channel  for  control  and  data  Information  flow  between 
a  maintenance  controller  end  the  modules  within  a  system.  The  module  In  control  of 
the  TM  Bus  Is  referred  to  as  the  "MASTER".  All  other  modules  on  the  bus  are 
referred  to  as  "SLAVES*.  The  Information  transferred  and  the  scheduling  of  data 
and  commands  Is  system  dependent  and  is  not  addressed  In  the  TM  bus 
Specification.  Table  3  •  TM  Bus  Design  Parameters  and  Characteristics  • 
summarizes  the  TM  Bus  design. 
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The  master  module  transmits  a  header  packet  and  selected  data  packets. 

The  slave  modules  respond  by  acknowledging  the  command  and/or  transmitting  any 
data  jackets  requested.  The  slave  will  only  transmit  data  packets  on  command  and 
will  indicate  Interrupts  with  an  appropriately  placed  interrupt  bit.  Complete  details  of 
TM  bus  operation  are  outlined  in  the  VHSIC  TM  bus  Specification. 

7.2.4  Element  TM  Bua 

The  TM  bus  serves  at  a  board  to  board  level.  The  Element  TM  bus  (ETM) 
is  a  6-  wire  bus  used  between  chips  on  a  board.  Thus,  each  VHSIC  chip  has  6  pins 
allocated  for  this  bus.  The  functions  include  a  clock,  data  In,  data  out,  interrupt, 
mode  and  select. 


0  Performance  Characteristics 

•  4-pin  bus  signals 

•  Synchronous  Operation 

•  Two  Data  Lines 

•  Module/board  compatible 
-  SLAVE  status  register 


Protocol  Characteristics 

•  8  reserved  address  bits 

•  32  module  addresses  (maximum) 

•  6  sub-addresses  per  module 
address 

-  Multi-drop  Configuration 

•  Interrupt  Capability 


TABLE  3 

TM  Bus  Design  Parameters  and  Charaoterlatiea 

o 
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MISSION 


of 

Rome  Air  Development  Center 


RADC  plans  and  executes  research,  development,  test  and 
selected  acquisition  programs  in  support  of  Command,  Control, 
Communications  and  Intelligence  (C*I)  activities.  Technical  and 
engineering  support  within  areas  of  competence  is  provided  to 
BSD  Program  Offices  (POs)  and  other  BSD  elements  to 
perform  effective  acquisition  of  C*I  systems.  The  areas  of 
technical  competence  include  communications,  command  and 
control,  battle  management  information  processing,  surveillance 
sensors,  intelligence  data  collection  and  handling,  solid  state 
sciences,  electromagnetics,  and  propagation,  and  electronic 
reliability /maintainability  and  compatibility. 


